オートスケールリソースを使用するようにバンドルを更新してください。

このガイドでは、既存のDatabricks アセットバンドル（DAB）を更新する方法について説明します。このアップデートにより、Lakebase Provisionedセットアップ（database_instancesリソースであり、オプションで子インスタンス、カタログ、および同期されたテーブルを含む）がLakebase オートスケールリソース（postgres_projects、postgres_branches、postgres_endpoints、およびオプションでpostgres_catalogs、postgres_synced_tables）に変換されます。

適用される場合

Lakebase データベースはすでにオートスケールプラットフォームで実行されています。2026年3月12日現在、データベースインスタンス API は、新しい Lakebase インスタンスをオートスケールプロジェクトとして作成します。バンドルだけが、まだそれらをdatabase_instancesを使用して参照しています。2026年6月から、Databricks は既存のプロビジョニングされたインスタンスをオートスケールに自動的にアップグレードします。どちらの場合も、バンドル更新ステップは同じです。

更新の仕組み

更新はインプレースです。Databricks はお客様のデータを移動またはコピーしません。バンドルはプロビジョニング済みリソースの追跡を停止し、オートスケールリソースを介して同じ基盤となるデータベースの管理を開始します。これにより、ゼロへのスケールや分岐などの機能が利用可能になります。

バンドル状態の遷移を管理するには、databricks bundle deployment bindコマンドとunbindコマンドの間に2つのdatabricks bundle deploy呼び出しが必要です。

プロビジョニングとオートスケールの概念的な違いについては、「オートスケールへのアップグレード」を参照してください。このページでは、バンドル構成の更新についてのみ説明しています。

前提条件

始める前に、以下が必要です:

Databricks CLI バージョン 1.2.0 以降は、既存のリソースをインプレースで更新します。バージョンを確認するには、databricks -v を実行します。
Databricks ワークスペース用に構成された認証。ワークスペースへのアクセスを構成するを参照してください。
Lakebase プロジェクトに対する CAN MANAGE 権限。「プロジェクトの権限を管理する」を参照してください。
既存のLakebaseデータベースは、バンドルによってdatabase_instancesとして現在管理されています。設定に子インスタンス、カタログ、または同期テーブルが含まれる場合、このガイドではそれらについても説明しています。

このページでは、database_instances、database_catalogs、synced_database_tables（同期テーブル）について説明します。Databricks Apps はまだ説明されていません。

リソースマッピング

プロビジョニング済み	オートスケール
親 `database_instances`	`postgres_projects` および暗黙的に作成される `production` ブランチ
子 `database_instances`	`postgres_branches` `branch_id` が子インスタンスのものと等しい `name`
子インスタンスの読み取り/書き込みエンドポイント	`postgres_endpoints` 子ブランチに`endpoint_id = "primary"`を含む
`database_catalogs`	`postgres_catalogs` `catalog_id`がカタログのものと等しい `name`
`synced_database_tables`	`postgres_synced_tables` `synced_table_id`が同期テーブルのものと等しい `name`

プロジェクト ID は、親プロジェクトのnameを小文字にしたものです。不明な点がある場合 (たとえば、名前に大文字が含まれていた場合) は、Lakebase アプリのプロジェクトリストでプロジェクトを見つけて、その project_id を確認してください。

ステップ 1：開始状態（プロビジョニング済み）

開始時のdatabricks.ymlは次のようになります。名前はプレースホルダーです。本名を使用してください。バンドルがdatabase_catalogsおよびsynced_database_tablesブロックを管理する場合にのみ、これらを含めてください。

YAML
resources:
  database_instances:
    root:
      name: my-instance
      capacity: CU_2
    child:
      name: my-child
      capacity: CU_2
      parent_instance_ref:
        name: ${resources.database_instances.root.name}

  database_catalogs:
    cat:
      name: my-catalog
      database_instance_name: ${resources.database_instances.root.name}
      database_name: my_db
      create_database_if_not_exists: true

  synced_database_tables:
    orders_synced:
      name: my-catalog.default.orders_synced
      database_instance_name: ${resources.database_instances.root.name}
      logical_database_name: my_db
      spec:
        scheduling_policy: SNAPSHOT
        source_table_full_name: main.default.orders
        primary_key_columns:
          - id
        new_pipeline_spec:
          storage_catalog: main
          storage_schema: default

ステップ 2 (デプロイ 1)：オートスケールリソースを導入する

既存のプロビジョニング済みのリソースと共に、オートスケールリソースをバンドルに追加します。プロビジョニングされたブロックは、このステップ中に設定に残ります。プロジェクト、ブランチ、エンドポイントは最小限のフィールド設定を使用します。カタログと同期テーブルには、同期テーブルのソーステーブル、プライマリキー、パイプラインストレージなど、さらにいくつかのフィールドが必要です。

YAML
resources:
  database_instances:
    root:
      name: my-instance
      capacity: CU_2
    child:
      name: my-child
      capacity: CU_2
      parent_instance_ref:
        name: ${resources.database_instances.root.name}

  database_catalogs:
    cat:
      name: my-catalog
      database_instance_name: ${resources.database_instances.root.name}
      database_name: my_db
      create_database_if_not_exists: true

  synced_database_tables:
    orders_synced:
      name: my-catalog.default.orders_synced
      database_instance_name: ${resources.database_instances.root.name}
      logical_database_name: my_db
      spec:
        scheduling_policy: SNAPSHOT
        source_table_full_name: main.default.orders
        primary_key_columns:
          - id
        new_pipeline_spec:
          storage_catalog: main
          storage_schema: default

  postgres_projects:
    pg_root:
      project_id: my-instance

  postgres_branches:
    pg_production:
      branch_id: production
      parent: ${resources.postgres_projects.pg_root.id}
    pg_child:
      branch_id: my-child
      parent: ${resources.postgres_projects.pg_root.id}

  postgres_endpoints:
    pg_child_rw:
      endpoint_id: primary
      parent: ${resources.postgres_branches.pg_child.id}
      endpoint_type: ENDPOINT_TYPE_READ_WRITE

  postgres_catalogs:
    pg_cat:
      catalog_id: my-catalog
      branch: ${resources.postgres_branches.pg_production.id}
      postgres_database: my_db
      create_database_if_missing: false

  postgres_synced_tables:
    pg_orders_synced:
      synced_table_id: my-catalog.default.orders_synced
      branch: ${resources.postgres_branches.pg_production.id}
      postgres_database: my_db
      source_table_full_name: main.default.orders
      primary_key_columns:
        - id
      scheduling_policy: SNAPSHOT
      new_pipeline_spec:
        storage_catalog: main
        storage_schema: default

注記

バンドルリソースキーは、単一のバンドル内で、すべてのリソースタイプにおいて一意でなければなりません。上記のオートスケールリソースは、既存のプロビジョニングキー（root、child、cat、orders_synced）との衝突を避けるために、pg_プレフィックスを使用します。

デプロイする前に、各オートスケールリソースを既存のバックエンドに**関連付けます**。バインディングによって、デプロイは新しいリソースを作成するのではなく、既存のリソースを採用することが保証されます。各bindコマンドのリソースIDは、ワークスペース内のリソースの正規名です：

Bash
databricks bundle deployment bind pg_root \
  projects/my-instance

databricks bundle deployment bind pg_production \
  projects/my-instance/branches/production

databricks bundle deployment bind pg_child \
  projects/my-instance/branches/my-child

databricks bundle deployment bind pg_child_rw \
  projects/my-instance/branches/my-child/endpoints/primary

databricks bundle deployment bind pg_cat \
  catalogs/my-catalog

databricks bundle deployment bind pg_orders_synced \
  synced_tables/my-catalog.default.orders_synced

バインディング後、バンドルをデプロイします：

Bash
databricks bundle deploy

デプロイによって、オートスケールリソースは再作成されることなくバンドル状態に組み込まれます。お客様のデータは影響を受けません。

ステップ 3 （Deploy 2）: バンドルの状態からプロビジョニングされたリソースを削除する

ステップ2でのデプロイがエラーなく完了した後、バンドルからプロビジョニング済み宣言を削除します。

各プロビジョニング済みリソースについて、bundle deployment unbindを実行します。次回のデプロイでは、プロビジョニング済みリソースを破棄せずに追跡を停止します。

Bash
databricks bundle deployment unbind orders_synced
databricks bundle deployment unbind cat
databricks bundle deployment unbind child
databricks bundle deployment unbind root

その後、バンドルYAMLからdatabase_instances（rootとchildの両方のエントリ）、database_catalogs、およびsynced_database_tablesのブロックを削除して、再デプロイしてください。

Bash
databricks bundle deploy

バンドルはプロビジョニング済みリソースを追跡しなくなりました。データはとどまります。ステップ2で導入されたオートスケールリソースは、お客様のデータベースを完全に管理します。

注記

unbind プロビジョニング済みのリソースをバンドルの追跡から削除することなく解除します。これにより、データベースは稼働を継続します。

Postgresロールとデータベース

Postgres ロールとデータベースは、バンドルリソースとしてではなく、データベース内に存在します。バンドルの更新では、それらは変更されません。それらはデータベースに残り、これまで通り利用可能です。

DABsは、Postgresロールまたはデータベースをバンドルリソースタイプとしてまだ提供していません。コードとして作成および管理するには、バンドルと合わせて databricks_postgres_role および databricks_postgres_database Terraform リソースを使用します。

バンドル更新後に可能なこと

オートスケールがプロジェクトを管理すると、プロビジョニングでは利用できなかったことができるようになります。ハイライト：

ブランチング。データベースのインスタントかつ分離されたコピーを、開発、テスト、またはリカバリのために作成します。保護されたブランチおよび特定時点のブランチングが含まれます。
ゼロにスケーリング。非アクティブなブランチのコンピュートを一時停止してコストを削減します。
「インスタントリストア」を参照してください。保持期間内（最大30日間）であれば、任意の時点に復元できます。
読み取りレプリカ。同じストレージを共有する個別の読み取り専用コンピュートエンドポイント。
スナップショット.ルートブランチの時点取得（手動またはスケジュール）

これらの多くを組み合わせて使用する完全なバンドルについては、DABでLakebaseを管理するを参照してください。

注記

後でプロジェクトを完全に廃止するために、databricks bundle destroy は Lakebase では機能しません（読み書きエンドポイントは個別に削除できません）。正しい方法については、リソースのクリーンアップを参照してください。

適用される場合​

更新の仕組み​

前提条件​

リソースマッピング​

ステップ 1：開始状態（プロビジョニング済み）​

ステップ 2 (デプロイ 1)：オートスケール リソースを導入する​

ステップ 3 （Deploy 2）: バンドルの状態からプロビジョニングされたリソースを削除する​

Postgresロールとデータベース​

バンドル更新後に可能なこと​

参照​