レイクベースデータAPI
ベータ版
Lakebase Postgres (オートスケール Beta) は 次のリージョンで利用できます: us-east-1 、 us-west-2 、 eu-west-1 。
このベータ リリースは Lakebase の次のバージョンであり、評価目的でのみ利用できます。本番運用ワークロードの場合は、 Lakebase Public Preview を使用します。 どのバージョンが適しているかを判断するには、バージョンの選択を参照してください。
Lakebase Data API は、標準の HTTP メソッドを使用して Lakebase Postgres データベースと直接対話できる、PostgREST 互換の RESTful インターフェースです。データベース スキーマから派生した API エンドポイントを提供し、カスタム バックエンド開発を必要とせずに、データに対する安全な CRUD (作成、読み取り、更新、削除) 操作を可能にします。
概要
Data API は、データベース スキーマに基づいて RESTful エンドポイントを自動的に生成します。データベース内の各テーブルは HTTP リクエストを通じてアクセスできるようになり、次のことが可能になります。
- 柔軟なフィルタリング、並べ替え、ページ区切りを備えた HTTP GET リクエストを使用して データをクエリします。
- HTTP POSTリクエストを使用して レコードを挿入する
- HTTP PATCHまたはPUTリクエストを使用して レコードを更新する
- HTTP DELETEリクエストを使用して レコードを削除する
- HTTP POSTリクエストを使用して ストアドプロシージャを実行する
このアプローチにより、カスタム API コードの作成と管理が不要になり、アプリケーション ロジックとデータベース スキーマに集中できるようになります。
Lakebase Data API は、PostgREST 仕様と互換性があるように設計された Databricks の実装です。つまり、Lakebase Data API で PostgREST ドキュメント、ツール、クライアント ライブラリを使用できることになります。Data API は独立した実装であるため、Lakebase 環境に適用できない一部の PostgREST 機能は含まれていません。機能の互換性の詳細については、 「PostgREST の互換性」を参照してください。
ユースケース
Lakebase Data API は次の場合に最適です。
- Web アプリケーション : HTTP リクエストを通じてデータベースと直接やり取りするフロントエンドを構築します。
- マイクロサービス : REST APIs経由でデータベース リソースにアクセスする軽量のサービスを作成します。
- サーバーレスアーキテクチャ ：サーバーレス機能とエッジコンピューティングプラットフォームとの統合
- モバイル アプリケーション : RESTful インターフェースを通じてモバイル アプリに直接データベース アクセスを提供します。
- サードパーティ統合 : 外部システムが安全にデータを読み書きできるようにする
データAPIを設定する
このセクションでは、必要なロールの作成から最初の API リクエストの作成まで、Data API の設定手順を説明します。
前提条件
Data APIを使用するには、Lakebase Postgres (オートスケール Beta) データベース プロジェクトが必要です。 まだお持ちでない場合は、 「データベース プロジェクトの開始」を参照してください。
認証ロールを作成する
すべてのデータベース アクセスは、 authenticatorという名前の単一の Postgres ロールを通じて行われます。このロールには、ログイン以外の権限は必要ありません。
データベースが存在するブランチにauthenticator Postgres ロールを作成します。たとえば、Data APIが本番運用ブランチのデータベースにアクセスする場合は、そのブランチにロールを作成します。
- SQL
- Console
Lakebase SQL エディターまたは任意の SQL クライアントを使用して、次の SQL ステートメントを実行します。
CREATE ROLE authenticator LOGIN NOINHERIT NOCREATEDB NOCREATEROLE NOSUPERUSER;
Lakebase アプリを通じてロールを作成します。
- ブランチの 「ロールとデータベース」 タブに移動します。
- 「ロールの追加」 をクリックし、ロール名として
authenticatorを指定します。 - 作成 をクリックします。
- 生成されたパスワードをコピーして安全に保存します (認証ロールでは通常、直接のパスワード ログインは必要ありませんが、トラブルシューティングで必要になる場合があります)。
データAPIを有効にする
Lakebase SQL エディターまたは任意の SQL クライアントを使用してデータベースでこれらの SQL ステートメントを実行し、Data API を有効にします。
これらのステートメントは、次の方法で Data API が機能するために必要なインフラストラクチャを設定します。
- API 構成を保存するための
pgrstスキーマを作成しています - API 経由でアクセス可能なデータベース スキーマを構成する (デフォルトでは
public) - APIレスポンスで集計関数（
SUM、COUNTなど）を有効にする authenticatorロールにpgrstスキーマおよび関数権限を付与します
CREATE SCHEMA IF NOT EXISTS pgrst;
CREATE OR REPLACE FUNCTION pgrst.pre_config()
RETURNS VOID AS $$
SELECT
set_config('pgrst.db_schemas', 'public', true),
set_config('pgrst.db_aggregates_enabled', 'true', true)
$$ LANGUAGE SQL;
GRANT USAGE ON SCHEMA pgrst TO authenticator;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA pgrst TO authenticator;
追加のスキーマ（ public以外）を公開する必要がある場合は、それらを含めるようにpgrst.db_schemas設定を変更します: set_config('pgrst.db_schemas', 'public,other_schema', true) 。
サンプルスキーマ（オプション）
このドキュメントの例では、次のスキーマを使用します。独自のテーブルを作成することも、このサンプル スキーマをテストに使用することもできます。Lakebase SQL エディターまたは任意の SQL クライアントを使用して、次の SQL ステートメントを実行します。
-- Create clients table
CREATE TABLE clients (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
email TEXT UNIQUE NOT NULL,
company TEXT,
phone TEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Create projects table with foreign key to clients
CREATE TABLE projects (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
description TEXT,
client_id INTEGER NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
status TEXT DEFAULT 'active',
start_date DATE,
end_date DATE,
budget DECIMAL(10,2),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Create tasks table with foreign key to projects
CREATE TABLE tasks (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
description TEXT,
project_id INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
status TEXT DEFAULT 'pending',
priority TEXT DEFAULT 'medium',
assigned_to TEXT,
due_date DATE,
estimated_hours DECIMAL(5,2),
actual_hours DECIMAL(5,2),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Insert sample data
INSERT INTO clients (name, email, company, phone) VALUES
('Acme Corp', 'contact@acme.com', 'Acme Corporation', '+1-555-0101'),
('TechStart Inc', 'hello@techstart.com', 'TechStart Inc', '+1-555-0102'),
('Global Solutions', 'info@globalsolutions.com', 'Global Solutions Ltd', '+1-555-0103');
INSERT INTO projects (name, description, client_id, status, start_date, end_date, budget) VALUES
('Website Redesign', 'Complete overhaul of company website with modern design', 1, 'active', '2024-01-15', '2024-06-30', 25000.00),
('Mobile App Development', 'iOS and Android app for customer management', 1, 'planning', '2024-07-01', '2024-12-31', 50000.00),
('Database Migration', 'Migrate legacy system to cloud database', 2, 'active', '2024-02-01', '2024-05-31', 15000.00),
('API Integration', 'Integrate third-party services with existing platform', 3, 'completed', '2023-11-01', '2024-01-31', 20000.00);
INSERT INTO tasks (title, description, project_id, status, priority, assigned_to, due_date, estimated_hours, actual_hours) VALUES
('Design Homepage', 'Create wireframes and mockups for homepage', 1, 'in_progress', 'high', 'Sarah Johnson', '2024-03-15', 16.00, 8.00),
('Setup Development Environment', 'Configure local development setup', 1, 'completed', 'medium', 'Mike Chen', '2024-02-01', 4.00, 3.50),
('Database Schema Design', 'Design new database structure', 3, 'completed', 'high', 'Alex Rodriguez', '2024-02-15', 20.00, 18.00),
('API Authentication', 'Implement OAuth2 authentication flow', 4, 'completed', 'high', 'Lisa Wang', '2024-01-15', 12.00, 10.50),
('User Testing', 'Conduct usability testing with target users', 1, 'pending', 'medium', 'Sarah Johnson', '2024-04-01', 8.00, NULL),
('Performance Optimization', 'Optimize database queries and caching', 3, 'in_progress', 'medium', 'Alex Rodriguez', '2024-04-30', 24.00, 12.00);
ユーザー権限を設定する
すべての Data API リクエストは、 Authorizationヘッダー経由で送信される Databricks OAuth ベアラー トークンを使用して認証する必要があります。アクセスは認証された Databricks ID に制限されており、基礎となる権限は Postgres によって管理されます。
authenticatorロールは、API リクエストを処理するときに、リクエスト元のユーザーの ID を引き継ぎます。これを機能させるには、Data API にアクセスする各 Databricks ID に、データベース内に対応する Postgres ロールが必要です。最初に Databricks アカウントにユーザーを追加する必要がある場合は、 「アカウントにユーザーを追加する」を参照してください。
Postgresロールを追加する
databricks_auth拡張機能を使用して、Databricks ID に対応する Postgres ロールを作成します。
拡張機能を作成します。
CREATE EXTENSION IF NOT EXISTS databricks_auth;
Postgres ロールを追加します。
SELECT databricks_create_role('user@databricks.com', 'USER');
詳細な手順については、 「SQL を使用して Databricks ID の OAuth ロールを作成する」を参照してください。
Data API にアクセスする際に、データベース所有者アカウント (Lakebase プロジェクトを作成した Databricks ID) を使用しないでください。authenticatorロールにはロールを引き受ける権限が必要ですが、昇格された権限を持つアカウントにはその権限を付与できません。
データベース所有者のロールをauthenticatorに付与しようとすると、次のエラーが表示されます。
ERROR: permission denied to grant role "db_owner_user@databricks.com"
DETAIL: Only roles with the ADMIN option on role "db_owner_user@databricks.com" may grant this role.
ユーザーに権限を付与する
Databricks ID に対応する Postgres ロールを作成したので、それらの Postgres ロールに権限を付与する必要があります。これらの権限は、各ユーザーが API リクエストを介してどのデータベース オブジェクト (スキーマ、テーブル、シーケンス、関数) と対話できるかを制御します。
標準 SQL GRANTステートメントを使用して権限を付与します。この例ではpublicスキーマを使用します。別のスキーマを公開する場合は、 publicスキーマ名に置き換えます。
-- Allow authenticator to assume the identity of the user
GRANT "user@databricks.com" TO authenticator;
-- Allow user@databricks.com to access everything in public schema
GRANT USAGE ON SCHEMA public TO "user@databricks.com";
GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA public TO "user@databricks.com";
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO "user@databricks.com";
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO "user@databricks.com";
この例では、 user@databricks.com ID にpublicスキーマへのフル アクセスを許可します。これを実際の Databricks ID に置き換え、要件に応じて権限を調整します。
行レベルのセキュリティを実装する : 上記の権限はテーブルレベルのアクセスを許可しますが、ほとんどの API 使用例では行レベルの制限が必要です。たとえば、マルチテナント アプリケーションでは、ユーザーは自分のデータまたは組織のデータのみを表示する必要があります。PostgreSQL の行レベル セキュリティ (RLS) ポリシーを使用して、データベース レベルできめ細かなアクセス制御を適用します。「行レベルのセキュリティを実装する」を参照してください。
認証
Data API にアクセスするには、HTTP リクエストのAuthorizationヘッダーに Databricks OAuth トークンを指定する必要があります。認証されたDatabricks ID には、データベース権限を定義する対応する Postgres ロール (前の手順で作成) が必要です。
OAuthローンを取得する
前のステップで Postgres ロールを作成したDatabricks ID としてワークスペースに接続し、 OAuthアカウントを取得します。 手順については認証を参照してください。
RESTエンドポイントを構築する
REST エンドポイント URL は、ワークスペース ID、データベース インスタンスのホスト名、データベース名、スキーマなどの複数のコンポーネントから構築されます。エンドポイントの形式は次のとおりです。
https://${DB_INSTANCE}/api/2.0/workspace/${WORKSPACE_ID}/rest/${DATABASE_NAME}/${SCHEMA}
データベース インスタンスのホスト名 ( DB_INSTANCE ) を取得するには、 「OAuth ロールを使用して接続する」を参照してください。 [接続] ダイアログから、ホスト名を含む接続文字列をコピーします。ホスト名は次のようになります。
ep-odd-poetry-xxxxxxxx.database.us-west-2.databricks.com
接続文字列の形式の詳細については、 「接続文字列について」を参照してください。
完全な REST エンドポイントの例を次に示します。
https://ep-odd-poetry-xxxxxxxx.database.us-west-2.databricks.com/api/2.0/workspace/1983801286941885/rest/databricks_postgres/public
このスクリプトを使用して、OAuth トークンを保存し、特定の値で REST エンドポイントを構築します。export_data_api_vars.shとして保存:
#!/bin/bash
export DBX_OAUTH_TOKEN="<paste the token here>"
WORKSPACE_ID="0000000000000000"
DB_INSTANCE="ep-odd-poetry-xxxxxxxx.database.us-west-2.databricks.com"
DATABASE_NAME="databricks_postgres"
SCHEMA="public"
export REST_ENDPOINT="https://${DB_INSTANCE}/api/2.0/workspace/${WORKSPACE_ID}/rest/${DATABASE_NAME}/${SCHEMA}"
プレースホルダーの値を実際の値に置き換えます。次に、 sourceを使用して実行し、環境変数をエクスポートします。
source export_data_api_vars.sh
sourceコマンド (または.短縮形) は現在のシェルでスクリプトを実行し、エクスポートされた変数を後続のコマンドで使用できるようにします。
リクエストを行う
OAuth トークンと REST エンドポイントを設定すると、curl または任意の HTTP クライアントを使用して API リクエストを行うことができます。次の例では、上記のヒントに示されているスクリプトを使用してDBX_OAUTH_TOKENおよびREST_ENDPOINT環境変数をエクスポートしていることを前提としています。
以下に、期待される出力を含む呼び出しの例を示します (サンプルの clients/projects/Task スキーマを使用)。
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/clients?select=id,name,projects(id,name)&id=gte.2"
応答例：
[
{ "id": 2, "name": "TechStart Inc", "projects": [{ "id": 3, "name": "Database Migration" }] },
{ "id": 3, "name": "Global Solutions", "projects": [{ "id": 4, "name": "API Integration" }] }
]
API の詳細な機能については、 PostgREST API リファレンスを参照してください。Lakebase 固有の互換性情報については、 「PostgREST 互換性」を参照してください。
APIリファレンス
次のセクションでは、一般的な操作、高度な機能、セキュリティに関する考慮事項、互換性の詳細など、Data API の使用に関するリファレンス情報を提供します。
基本操作
クエリレコード
HTTP GET を使用してテーブルからレコードを取得します。
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/clients"
応答例：
[
{ "id": 1, "name": "Acme Corp", "email": "contact@acme.com", "company": "Acme Corporation", "phone": "+1-555-0101" },
{
"id": 2,
"name": "TechStart Inc",
"email": "hello@techstart.com",
"company": "TechStart Inc",
"phone": "+1-555-0102"
}
]
結果をフィルタリング
クエリを使用して結果をフィルタリングします。 この例では、 idが 2 以上のクライアントを取得します。
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/clients?id=gte.2"
応答例：
[
{ "id": 2, "name": "TechStart Inc", "email": "hello@techstart.com" },
{ "id": 3, "name": "Global Solutions", "email": "info@globalsolutions.com" }
]
特定の列を選択してテーブルを結合する
select問題を使用して、特定の列を取得し、関連するテーブルを結合します。
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/clients?select=id,name,projects(id,name)&id=gte.2"
応答例：
[
{ "id": 2, "name": "TechStart Inc", "projects": [{ "id": 3, "name": "Database Migration" }] },
{ "id": 3, "name": "Global Solutions", "projects": [{ "id": 4, "name": "API Integration" }] }
]
レコードを挿入する
HTTP POST を使用して新しいレコードを作成します。
curl -X POST \
-H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "New Client",
"email": "newclient@example.com",
"company": "New Company Inc",
"phone": "+1-555-0104"
}' \
"$REST_ENDPOINT/clients"
レコードを更新する
HTTP PATCH を使用して既存のレコードを更新します。
curl -X PATCH \
-H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{"phone": "+1-555-0199"}' \
"$REST_ENDPOINT/clients?id=eq.1"
レコードを削除する
HTTP DELETE を使用してレコードを削除します。
curl -X DELETE \
-H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/clients?id=eq.5"
高度な機能
ページネーション
limitとoffsetを使用して返されるレコードの数を制御します。
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/tasks?limit=10&offset=0"
ソート
order問題を使用して結果を並べ替えます。
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/tasks?order=due_date.desc"
複雑なフィルタリング
複数のフィルター条件を組み合わせる:
curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
"$REST_ENDPOINT/tasks?status=eq.in_progress&priority=eq.high"
一般的なフィルター演算子:
eq- 等しいgte- より大きいか等しいlte- 以下neq- 等しくないlike- パターンマッチングin- リスト内の任意の値に一致
サポートされているクエリとAPI機能の詳細については、「 PostgREST APIリファレンス」を参照してください。 Lakebase 固有の互換性情報については、 「PostgREST 互換性」を参照してください。
行レベルのセキュリティ
行レベル セキュリティ (RLS) ポリシーは、テーブル内のユーザーがアクセスできる行を制限することで、きめ細かなアクセス制御を提供します。
RLS が Data API と連携する仕組み : ユーザーが API リクエストを行うと、 authenticatorロールがそのユーザーの ID を引き継ぎます。そのユーザーのロールに対して定義された RLS ポリシーは PostgreSQL によって自動的に適用され、ユーザーがアクセスできるデータがフィルタリングされます。これはデータベース レベルで行われるため、アプリケーション コードがすべての行をクエリしようとしても、データベースはユーザーが表示を許可されている行のみを返します。これにより、アプリケーション コードにフィルタリング ロジックを必要とせずに、多層防御のセキュリティが実現します。
RLS がAPIsにとって重要な理由 : 接続コンテキストを制御する直接的なデータベース接続とは異なり、HTTP APIs単一のエンドポイントを通じてデータベースを複数のユーザーに公開します。 テーブル レベルの権限のみでは、ユーザーがclientsテーブルにアクセスできる場合、フィルタリングを実装しない限り、 すべての クライアント レコードにアクセスできることになります。RLS ポリシーにより、各ユーザーは許可されたデータのみを自動的に表示できるようになります。
RLS は以下にとって不可欠です:
- マルチテナントアプリケーション : 異なる顧客または組織間でデータを分離します
- ユーザー所有データ : ユーザーが自分の記録にのみアクセスできるようにする
- チームベースのアクセス : チームメンバーまたは特定のグループへの表示を制限します
- コンプライアンス要件 : データベースレベルでデータアクセス制限を適用する
テーブルで RLS を有効にし、アクセス ルールを定義するポリシーを作成します。
ALTER TABLE "clients" ENABLE ROW LEVEL SECURITY;
CREATE POLICY "restrict client access" ON "clients"
AS PERMISSIVE FOR SELECT TO "user@databricks.com"
USING (id IN (1, 2));
特定のテーブルで RLS が有効になっている場合、RLS の対象となるロールには、少なくとも 1 つのポリシーに一致する行のみが表示され、その他の行はすべてフィルター処理されます。上記の例では、 user@databricks.comテーブル全体に対してSELECT権限を持っているにもかかわらず、 clientsテーブル内でidが 1 または 2 である行のみを表示するように制限されています。
Data API の一般的な RLS パターン:
- ユーザー所有権 :
USING (user_email = current_user)- 行を認証されたユーザーに制限します - テナント分離 :
USING (tenant_id = (SELECT tenant_id FROM user_tenants WHERE user_email = current_user))- ユーザーのテナントに制限します - チームメンバーシップ :
USING (team_id IN (SELECT team_id FROM user_teams WHERE user_email = current_user))- ユーザーのチームに制限します - ロールベースのアクセス :
USING (pg_has_role(current_user, required_role, 'member'))- ロールのメンバーシップに基づいて制限します
Lakebase では、 current_userは認証されたユーザーの電子メール アドレス (例: user@databricks.com ) を返します。 RLS ポリシーでこれを使用して、どのユーザーがリクエストを行っているかを識別します。
ポリシーのタイプ、セキュリティのベスト プラクティス、高度なパターンなど、RLS の実装に関する包括的な情報については、 PostgreSQL行セキュリティ ポリシーのドキュメントを参照してください。
権限の詳細については、 「権限の管理」を参照してください。
PostgREST互換性
Lakebase Data API はPostgREST仕様と互換性があります。あなたはできる：
- 既存のPostgRESTクライアントライブラリとツールを使用する
- フィルタリング、順序付け、ページ区切りについては PostgREST の規則に従ってください。
- PostgREST コミュニティのドキュメントと例を適応させる
Lakebase Data API は独立した実装であり、オープンソースの PostgREST プロジェクトに基づいていません。したがって、Lakebase 環境に適用できない特定の PostgREST 機能または構成は含まれていません。
API機能、クエリ、機能の包括的な詳細については、「 PostgREST APIリファレンス」を参照してください。
機能互換性リファレンス
このセクションでは、Lakebase Data API で動作が異なる、またはサポートされていない PostgREST 機能を一覧表示します。
認証と承認
機能 | ステータス | 詳細 |
|---|---|---|
JWT構成 | 該当なし | Lakebase Data API は、JWT 認証の代わりに Databricks OAuth トークンを使用します。JWT 固有の構成オプション (カスタム シークレット、RS256 キー、オーディエンス検証) は使用できません。 |
リソースの埋め込み
機能 | ステータス | 詳細 |
|---|---|---|
コンピュート関係 | サポートされていない |
|
内部結合埋め込み（ | サポートされていない | 子の基準に基づいて親行をフィルタリングするために左結合を内部結合に変換する |
応答形式
機能 | ステータス | 詳細 |
|---|---|---|
カスタムメディアタイプハンドラー | サポートされていない | PostgreSQL 集計によるカスタム出力形式 (バイナリ形式、XML、プロトコル バッファ) はサポートされていません。 |
ストリップされたヌル | サポートされていない | JSON 応答から null フィールドを削除する |
PostGIS GeoJSON | 部分的にサポート | PostGIS ジオメトリ列をクエリすることはできますが、 |
ページ番号とカウント
機能 | ステータス | 詳細 |
|---|---|---|
予定数 | サポートされていない | PostgreSQL のクエリ プランナーを使用して結果数を推定する |
推定数 | サポートされていない | おおよそのカウントに PostgreSQL 統計を使用する |
リクエストの設定
機能 | ステータス | 詳細 |
|---|---|---|
タイムゾーンの設定 | 部分的にサポート | タイムゾーンの処理は存在しますが、サーバーのタイムゾーンをオーバーライドするための |
トランザクション制御 | サポートされていない |
|
優先処理モード | サポートされていない | 無効な設定の処理方法を制御するための |
可観測性
Lakebase Data API は独自の監視機能を実装します。次の PostgREST 可観測性機能はサポートされていません。
機能 | ステータス | 詳細 |
|---|---|---|
クエリプランの公開 | サポートされていない | パフォーマンス分析用の PostgreSQL EXPLAIN 出力を公開する |
サーバータイミングヘッダー | サポートされていない | リクエストのタイミングの内訳を提供する Server-Timing ヘッダーはサポートされていません。Lakebase は独自の観測可能性機能を実装しています。 |
トレースヘッダーの伝播 | サポートされていない | 分散トレースの X-Request-Id およびカスタム トレース ヘッダーの伝播はサポートされていません。Lakebase は独自の観測可能性機能を実装しています。 |
高度な設定
機能 | ステータス | 詳細 |
|---|---|---|
アプリケーション設定（GUC） | サポートされていない | PostgreSQL GUC を介してデータベース関数にカスタム構成値を渡すことはサポートされていません。 |
事前リクエスト機能 | サポートされていない | 各リクエストの前に実行するデータベース関数を指定できる |
PostgREST 機能の詳細については、 PostgREST ドキュメントを参照してください。
セキュリティに関する考慮事項
Data API は、データベースのセキュリティ モデルを複数のレベルで適用します。
- 認証 : すべてのリクエストには有効なOAuth認証が必要です
- ロールベースのアクセス : データベースレベルの権限は、ユーザーがアクセスできるテーブルと操作を制御します。
- 行レベルのセキュリティ : RLS ポリシーはきめ細かなアクセス制御を実施し、ユーザーが表示または変更できる特定の行を制限します。
- ユーザーコンテキスト : APIは認証されたユーザーのIDを想定し、データベースの権限とポリシーが正しく適用されるようにします。
推奨されるセキュリティ対策
本番運用デプロイメントの場合:
- 行レベルのセキュリティを実装する : RLS ポリシーを使用して、行レベルでのデータ アクセスを制限します。これは、マルチテナント アプリケーションやユーザー所有のデータにとって特に重要です。行レベルのセキュリティを参照してください。
- 最小限の権限を付与する : 広範なアクセスを許可するのではなく、特定のテーブルに対してユーザーが必要とする権限 (
SELECT、INSERT、UPDATE、DELETE) のみを付与します。 - アプリケーションごとに個別のロールを使用する : 単一のロールを共有するのではなく、異なるアプリケーションまたはサービスに専用のロールを作成します。
- アクセスを定期的に監査する : 付与されたアクセス許可と RLS ポリシーを定期的に確認し、セキュリティ要件を満たしていることを確認します。
役割と権限の管理については、次を参照してください。