メインコンテンツまでスキップ

オートスケールへのアップグレード

Lakebase はオートスケーリングに全面的に移行します。

新しいインスタンスはオートスケール プロジェクトとして作成されます

新しい Lakebase インスタンスを作成すると、 Lakebase オートスケール プロジェクトとして作成され、プロビジョニング ページではなく、Lakebase アプリの オートスケール ページに表示さ ます。 既存のプロビジョニングされたインスタンスは影響を受けず、以前とまったく同じように実行され続けます。

オートスケールの ページでは、新しいプロジェクトには情報アイコンが付いています。

アイコンにカーソルを合わせると、プロジェクトがDatabase instance API を使用して作成されたこと、およびDatabase instance API と Postgres APIs の両方に対応していることを説明するツールチップが表示されます。

オートスケール ページのデータベース インスタンス プロジェクト

これがあなたにとって何を意味するか

  • Lakebase インスタンスの作成。 新しい Lakebase インスタンスは、Lakebase オートスケール プロジェクトとして作成され、Lakebase アプリの オートスケール ページに表示されます。 これらのプロジェクトは、データベース インスタンス APIPostgres API の両方を使用して管理できます。
  • UI の [作成] ボタン。 [作成] ボタン ([プロビジョニング] タブに含まれる) をクリックすると、オートスケール プロジェクトの作成フローが開きます。
  • オートスケール機能。 新しいプロジェクトでは、オートスケール コンピュート、スケールゼロ(24時間のアクティビティタイムアウトでデフォルトで有効)、分岐、即時復元などのオートスケール機能が利用できます。準備ができましたら、Lakebase オートスケール UI と Postgres API からこれらの機能にアクセスできます。プロビジョニングとの完全な比較については、機能比較表を参照してください。
  • 既存のプロビジョニングされたインスタンスは変更されません。 以前と同じ動作で、UI の プロビジョニング済み ページに留まります。プロビジョニング インスタンス、接続文字列、APIsはすべて動作し続けます。
  • 既存のオートメーションは引き続き機能します。 既存のオートメーションは変更なしで動作し続けますが、新しいインスタンスはオートスケールプロジェクトとして作成されます。

APIs

データベース インスタンス API を使用して作成された新しいインスタンスは両方のAPIをサポートしているため、既存の自動化は変更なしで継続されます。

インスタンスまたはプロジェクト

使用するAPI

データベースインスタンス API を使用して作成された新しいプロジェクト

両方の APIs です。同じプロジェクトをいずれかを使用して管理できます。

オートスケール UI または Postgres API を使用して作成されたプロジェクト

Postgres APIのみ。

オートスケーリングへのアップグレード前の既存のプロビジョニングされたインスタンス

データベース インスタンス APIのみ。

オートスケーリングへのアップグレード後の 既存のプロビジョニングされたインスタンス

両方の APIs。どちらの方法でも、同じインスタンスを管理できます。

インスタンスまたはプロジェクト

使用するAPI

データベースインスタンス API を使用して作成された新しいプロジェクト

両方の APIs です。同じプロジェクトをいずれかを使用して管理できます。

オートスケール UI または Postgres API を使用して作成されたプロジェクト

Postgres APIのみ。

オートスケーリングへのアップグレード前の既存のプロビジョニングされたインスタンス

データベース インスタンス APIのみ。

オートスケーリングへのアップグレード後の 既存のプロビジョニングされたインスタンス

両方の APIs。どちらの方法でも、同じインスタンスを管理できます。

database_instancesを使用する既存のDAB自動化は引き続き機能します。ただし、database_instancesによって作成された新しいインスタンスはオートスケール プロジェクトとして作成されます。Databricks では、新規 Lakebase の作業には、代わりに postgres_projects を使用することをお勧めします。バンドルリソースを参照してください。

新しいLakebaseインスタンスの違い

コンピュートサイズ

オートスケール プロジェクトとして作成された Lakebase インスタンスは、Lakebase Provisioned キャパシティ ユニットの代わりにオートスケール コンピュート ユニット (CU) を使用します。データベース インスタンス API を使用してプロジェクトを作成すると、Lakebase は、選択されたプロビジョニング済みキャパシティユニットを、次のように最小および最大オートスケール CU 範囲にマッピングします。

注記

ユニットあたりの RAM: Lakebase Provisionedでは、1 つの容量ユニットに 16 GB の RAM が搭載されています。 Lakebase オートスケールでは、1 つの CU に 2 GB の RAM が搭載されています。

プロビジョニングされた容量

オートスケール min CU

オートスケールマックスCU

1 (16 GB)

4 (8GB)

8 (16 GB)

2 (32 GB)

8 (16 GB)

16 (32 GB)

4 (64 GB)

16 (32 GB)

32 (64 GB)

8 (128 GB)

48(96 GB)

64 (128 GB)

プロビジョニングされた容量

オートスケール min CU

オートスケールマックスCU

1 (16 GB)

4 (8GB)

8 (16 GB)

2 (32 GB)

8 (16 GB)

16 (32 GB)

4 (64 GB)

16 (32 GB)

32 (64 GB)

8 (128 GB)

48(96 GB)

64 (128 GB)

たとえば、自動化によって、**容量1**のLakebaseインスタンスが作成される場合、新しいLakebaseオートスケール プロジェクトは**最小CU 4**および**最大CU 8**の設定で作成されます。min/maxは、後でPostgres APIを使用するか、Lakebase オートスケール UI で変更できます。

注記

価格プラン

データベースインスタンス API を使用して作成されたものを含む、すべての新しいインスタンスは、オートスケール プラットフォーム上で稼働し、Lakebase オートスケール 価格 を使用します。固定容量課金に代わるエラスティック コンピュートにより、ほとんどの顧客はコンピュートコストの削減を実感できます。既存のプロビジョニングされたインスタンスは、アップグレードされるまでは現在の価格が適用され続けます。既存のプロビジョニングされたインスタンスのオートスケールへのアップグレードをご覧ください。

スケールゼロ

新しいプロジェクトの読み取り/書き込みエンドポイントは 、24 時間の非アクティブ タイムアウト を備えた ゼロへのスケールが有効になっている ため、コストを削減するために 24 時間の非アクティブ状態が続くとコンピュートが自動的に一時停止されます。 Lakebaseオートスケール UI またはPostgres APIを使用して、タイムアウトを調整したり、ゼロへのスケールを無効にしてコンピュートを常に実行し続けることができます。 詳細については、 「スケールをゼロにする」を参照してください。

履歴ウィンドウ

Lakebase Provisioned (データベース インスタンス)では、 復元ウィンドウを 最大 35 日間 設定できます。 Lakebase オートスケール (新しいプロジェクト)では、 履歴ウィンドウ 設定は最大**30 日間**です。

PostgreSQLバージョン

Database インスタンスAPIまたはレイクハウス/プロビジョニング UI を通じて作成された新しいプロジェクトは、Lakebase Provisionedと連携した PostgreSQL 16 を 使用します。 つまり、データベース インスタンス API を使用した自動化では、以前と同じ PostgreSQL バージョン (16) のプロジェクトが作成されることになります。オートスケール UI またはPostgres APIを使用して作成されたプロジェクトの安全性は PostgreSQL 17 です。

接続の詳細とホスト名

新しいプロジェクトの接続の詳細には、Lakebase Provisionedとは異なる ホスト名形式 が使用されます。 プロビジョニングされたインスタンスは、 グローバル ホスト名 (ホスト名にリージョンはありません) を使用します。新しく作成されたプロジェクトでは、 地域 ホスト名 (地域を含む) が使用されます。読み取り/書き込みエンドポイントと読み取り専用エンドポイントの両方で、新しいプロジェクトに地域のホスト名形式が使用されます。

プロビジョニング済み(グローバルホスト名):

Text
host=instance-a1b2c3d4-e5f6-7890-abcd-ef1234567890.database.cloud.databricks.com

オートスケール (地域ホスト名):

Text
host=ep-example-endpoint-a1b2c3d4.database.<region>.cloud.databricks.com

リージョン ホスト名には、クラウドとリージョンのリージョン コードが含まれます (たとえば、AWS ではus-east-1 、Azure ではeastus )。

重要

IP 許可リストを使用する場合は、新しいプロジェクトに対してリージョンのリージョン Ingress IP を許可する必要があります。「ワークスペースの IP アクセス リストを作成する」を参照してください。

プライベートリンク

Lakebase オートスケールは、APIアクセス用の**フロントエンドPrivate Link**(ワークスペースレベルの接続は変更なし)と、Postgresクライアント接続用の**パフォーマンス重視のサービス用インバウンドPrivate Link**( パフォーマンス重視のサービス用インバウンドPrivate Link )の2つのPrivate Linkエンドポイントを使用します。パフォーマンス集約型サービス向けにインバウンド Private Link が必要かどうかは、アプリケーションがどのように接続するかによって異なります。

あなたの状況

必要なもの

Private Link を使用し、新しいインスタンスを作成し、Postgres クライアントを使用して Databricks ワークスペースの外部から接続します

パフォーマンス重視のサービス向けに、受信プライベートリンクを追加します。

すでにLakebaseオートスケール、またはパフォーマンス重視のサービスにインバウンド プライベート リンクを使用するその他のサービスを使用しています。

変更はありません。

既存のプロビジョニングされたインスタンスのみを使用し、新しいインスタンスは作成しません

変更はありません。

あなたの状況

必要なもの

Private Link を使用し、新しいインスタンスを作成し、Postgres クライアントを使用して Databricks ワークスペースの外部から接続します

パフォーマンス重視のサービス向けに、受信プライベートリンクを追加します。

すでにLakebaseオートスケール、またはパフォーマンス重視のサービスにインバウンド プライベート リンクを使用するその他のサービスを使用しています。

変更はありません。

既存のプロビジョニングされたインスタンスのみを使用し、新しいインスタンスは作成しません

変更はありません。

権限(ACL)

新しい Lakebase インスタンスのアクセス許可は、Lakebase プロジェクト ACLリソースに保存されます。標準のPermissions APIrequest_object_type=database-projects、Lakebase オートスケール UI、またはPostgres APIを使用して管理できます。既存の自動化がDatabase instance API を使用していても、これらの呼び出しが同じ database-projects リソースにプロキシされるため、引き続き機能します。読み取りと書き込みは、両方のAPIサーフェスにおいて一貫しています。

以前の権限モデル

2026年3月12日から5月11日の間にデータベースインスタンスAPIまたは関連ツール(CLI、SDK、Terraform、DAB)を使用して作成されたLakebaseプロジェクトでは、2つの独立したACLセットが適用される以前の権限モデルが使用されていました。

  • データベースインスタンスのACL: データベースインスタンスAPIを通じて設定および評価されます。
  • Lakebaseプロジェクト ACL: Lakebaseオートスケール UI またはPostgres APIを通じて設定および評価されます。

この2つのセットは、異なるレベルのアクセス権限を付与できる。有効な権限を理解するために、データベースインスタンスLakebaseプロジェクトの両方のACLセットを確認してください。Databricksは、今後のアップデートでこれらのインスタンスのアクセス権限を統一する予定です。

プロジェクト名とインスタンス名

データベース インスタンス APIまたはレイクハウス/プロビジョニング UI を使用して Lakebase インスタンスを作成すると、指定したインスタンス名が、結果の Lakebase オートスケール プロジェクトのプロジェクト ID(project_id)になります。ルートブランチは常にID production で作成されます。

インスタンス名とプロジェクト ID は**DNSに準拠している**必要があります。プロジェクト IDABC``abcの一意性は**大文字と小文字を区別しません**。つまり、同じワークスペース内で と の両方をプロジェクト ID として指定することはできません。Postgres APIを使用する場合、小文字のプロジェクトIDを使用してください。プロジェクトIDが既存のプロジェクトIDと競合する場合、作成に失敗します。

プロジェクトには表示名(display_name)もありますが、これはプロジェクト ID とは独立しており、DNS のコンプライアンス要件の対象外です。

Postgres APIでは、プロジェクトリソースnameは、データベースインスタンスAPIで使用されるプレーンなインスタンス名ではなく、パス形式projects/{project_id}(例:projects/my-instance)で返されます。プロジェクトのリストを参照してください。

ブランチとプロジェクトの名前変更

インスタンス名と同様に、プロジェクトIDとブランチIDは作成後に変更することはできません。しかし、プロジェクトには、いつでも更新できる表示名(display_name)もあります。

子データベースインスタンス

データベース インスタンスの場合 (子インスタンスはオートスケール プロジェクトのブランチに対応します):

  • ブランチ ID. データベース インスタンス APIで指定する子インスタンス名は、オートスケール UIでのブランチIDになります。
  • ブランチ制限。 Postgres APIまたはオートスケール UI を使用すると、任意の数のブランチを作成できます。 データベース インスタンス APIでは、親インスタンス (ルート ブランチ 1 つ) と子インスタンス (子ブランチ 1 つ) を 1 つだけ作成できます。これは、以前のデータベース インスタンス API の動作と一致します。
  • タグと予算 カスタムタグと使用ポリシーは、親ブランチから継承されます。これは以前のデータベース インスタンス APIの動作から変更されており、子インスタンスが独自の個別の値を持っていました。
  • 子インスタンスを削除しています。 子インスタンスに対応するプロジェクトで Lakebase オートスケール UI または Postgres APIを使用して追加のブランチを作成した場合、それらのブランチがすべて削除されるまで、レイクハウス/プロビジョニング UI またはAPIを通じてその子インスタンスを削除することはできません。 まずブランチを削除し (オートスケール UI または Postgres APIを使用)、次に子インスタンスを削除します。

保護されたブランチ

データベース インスタンスAPIを使用して作成されたプロジェクトのブランチを保護した場合 (ブランチが子インスタンスに対応しているか、作成した他のブランチに対応しているかに関係なく)、ブランチの保護が解除されるまで、レイクハウス/マルウェア UI またはAPIを使用してその子インスタンスまたはルート (親) インスタンスを削除することはできません。 まず Lakebase オートスケール UI でブランチの保護を解除してから、インスタンスを削除します。 保護されたブランチを参照してください。

プライベートプレビュー機能

新しく作成されたプロジェクトは Lakebase オートスケール プロジェクトであり、Lakebase ProbijoningData APIForward ETL プライベート プレビュー機能はサポートされていません。 これらはプロビジョニングに関する別のサービスでした。

  • REST APIアクセス (PostgREST スタイル): Lakebase オートスケールには、PostgREST 互換のRESTアクセス (CRUD、クエリ、RPC) 用の独自のデータAPIあります。

  • レイクハウスへのデータの同期: Lakebase オートスケールにはLakebase チェンジデータフィードがあり、Lakebase Provisionedのプライベート プレビュー Forward ETLとは異なります。

既存のプロビジョニングされたインスタンスのオートスケールへの移行

Databricksは、すべてのLakebase ProvisionedインスタンスをLakebase オートスケール プラットフォームにアップグレードしています。リクエストされた顧客向けに、2026年6月にアップグレードが開始され、残りのインスタンスアップグレードはその後数週間にわたり継続されます。ワークスペース管理者は、アップグレード開始前にアップグレード日程が記載されたEメールを受け取ります。

アップグレードは自動です。接続は移行中に一時的に再起動します。 既存の接続文字列、API呼び出し、宣言型オートメーションバンドル、およびTerraform構成は、引き続き変更なしで動作します。

注記

アップグレードはコンピュートプラットフォームのみを変更し、データは変更しません。すべてのデータベース オブジェクトは保持されます:スキーマ、テーブル、インデックス、主キー、外部キー、Postgres ロール、権限付与。DLT パイプライン ID も保持されます。

アップグレード後、以下の変更が適用されます。

  • コンピュートのサイジング。 インスタンスのプロビジョニング済み容量は、オートスケールの最小/最大 CU 範囲にマッピングされます。マッピングテーブルについては、コンピュートサイズを参照してください。アップグレード後、Lakebase オートスケール UI または Postgres API を使用して、最小/最大 CU を変更できます。

  • 両方のUIをご利用いただけます。 新しいオートスケール UI と、2026年9月1日まで引き続き利用可能な使い慣れたプロビジョニング UI の両方を使用して、インスタンスを管理できます。

  • プロジェクト名と表示名です。 アップグレードにより、プロジェクト ID および UID が維持されます。表示名 (display_name) に (upgraded) サフィックスが付与されるため、my-instance という名前のインスタンスはオートスケール UI とPostgres APImy-instance (upgraded) と表示されます。アップグレードされたインスタンスは、データベース インスタンス API と Postgres API の両方に表示され、それぞれ同じUIDを持ちます。

  • 新しい地域の接続文字列 各インスタンスには、イングレスが最適化された新しいリージョン接続文字列が割り当てられます。既存のグローバル接続文字列はプロビジョニング済み UI で、新しいリージョン接続文字列はオートスケール UI で確認できます。

    • 既存の接続文字列です。 プロビジョニング済み接続文字列(リージョンなし)は、既存のInbound PrivateLinkで引き続き機能し、Service Direct Private Linkは必要ありません。
    • 新しい地域の接続文字列 Databricks ワークスペースの外部から Private Link を使用して Lakebase に接続する場合、新しいリージョン接続文字列を使用するには、パフォーマンス重視のサービス用に受信 Private Link を構成する必要があります。
  • DABs および Terraform スケール・ツー・ゼロなどの新しいオートスケール機能を使用するには、バンドルを更新してpostgres_projectsを使用するか(バンドルリソースを参照)、またはTerraformで「databricks_postgres_project」リソースを使用してください。Terraform の手順については、Autoscaling リソースを使用するように Terraform 設定を更新する を参照してください。

  • Forward ETL (プライベートプレビュー)。 Lakebase ProvisionedのForward ETLプライベートプレビュー機能は、サポートされなくなり、今後のアップデートで利用できなくなります。アップグレード後も Lakehouse へデータを同期し続けるには、オートスケールプラットフォームで Lakebase チェンジデータフィード を設定してください。

  • REST API、PostgREST(プライベート プレビュー)。 Lakebase Provisioned の REST API (PostgREST) プライベートプレビュー機能は、アップグレード後も引き続き機能しますが、サポート対象外となり、将来のアップデートでは利用できなくなります。その後継であるData APIは、オートスケールプラットフォームで利用可能です。

  • 高可用性。 プロビジョニングされたインスタンスで高可用性が有効になっていた場合、アップグレード後も維持されます。

  • オートスケール強化 インスタンスはオートスケール機能をサポートしています。Lakebase Autoscaling は、オートスケールスケールツーゼロポイントインタイムリカバリスナップショットメンテナンスウィンドウのスケジューリングデータベースブランチ、およびその他の機能強化を追加します。詳細については、「Lakebase オートスケール」を参照してください。

注記

アップグレードされたインスタンスでは、ゼロにスケーリングは デフォルトでは有効になっていません 。24時間のアクティビティタイムアウトでデフォルトでゼロにスケーリングが有効になっている新しいインスタンスとは異なり、アップグレードされたインスタンスでは、ゼロにスケーリングを手動で有効にする必要があります。ゼロにスケーリングを参照してください。

  • 最適化されたストレージキャッシュ アップグレード後、Lakebase はストレージキャッシュ内でプロジェクトのルートブランチのデータを優先し、クエリのレイテンシを最適化します。アップグレード後に、保護されたブランチとしてマークすることで、別のブランチを優先できます。

  • ブランチ別のロールとデータベース Lakebase オートスケーリングには、ブランチごとにPostgresロールが500個、データベースが500個という上限があります。Lakebase Provisionedには、そのような制限はありませんでした。これらの制限を超えるインスタンスの場合、アップグレードは正常に完了しますが、その後、追加のロールやデータベースを作成することはできません。お使いのインスタンスが影響を受けていると思われる場合は、アカウントチームまたはDatabricksサポートにお問い合わせください。

  • 一時停止インスタンス アップグレード後、一時停止されたインスタンスに接続すると、The endpoint has been disabled. Enable it using the API and retryエラーが返されます。アクセスを復元するには、プロビジョニング UI またはデータベース インスタンス API を使用してインスタンスを起動するか、Lakebase オートスケーリング API を使用して update_mask=spec.disabledspec.disabled: false を設定します。

  • 価格. Lakebase GA 価格はアップグレード後に適用されます。伸縮自在なコンピュートが固定サイズのインスタンスに取って代わることで、ほとんどの顧客はコンピュートコストの削減を実感しています。Lakebase オートスケールには、常時オンのコンピュート価格も含まれます。現在の料金については、Lakebase 価格ページを参照してください。

  • Feature Store and Model Serving. Databricks オンライン Feature Store は、Lakebase オートスケールを基盤としています。既存の Feature Serving および モデルサービング のワークロードは、アクションは不要で引き続き動作します。create_online_store および update_online_store インターフェイスは、Feature Engineering クライアントを介して管理するオンラインストアに対して変更は不要です。See Feature Store and Model Serving.

  • Databricks Apps. Lakebase database リソースを使用するアプリは、アップグレード後も引き続き機能します。接続の詳細、環境変数、およびPostgresロールは変更されていません。アプリの設定で、databasepostgresに変更しないでください。これを行うと、新しいPostgresロールが作成され、既存のデータへのアクセスが中断されます。新しいアプリには、app.resources.postgresを使用してください。Databricks AppsにLakebaseリソースを追加を参照してください。

  • Model Serving 上のエージェント Lakebase接続を持つエージェントは、アップグレード後も引き続き動作します。Databricks では、オートスケール機能を利用するために、エージェントをDatabricks Appsに移行することをお勧めします。モデルサービングからDatabricks Appsへのエージェントの移行を参照してください。

迅速なアップグレードをリクエストする場合、またはご質問がある場合は、アカウントチームまたはDatabricks Support にお問い合わせください。

その他のリソース