オートスケール リソースを使用するように Terraform の構成を更新します

このガイドでは、既存のTerraform構成を更新して、Lakebase オートスケール リソース（databricks_postgres_project、databricks_postgres_branch、databricks_postgres_endpoint）を使用する方法を説明します。

適用される場合

このガイドに従う前に、Lakebase インスタンスがオートスケールにアップグレードされていることを確認してください。2026年3月12日以降、Database instance API を通じて作成された新しい Lakebase インスタンスはオートスケール プロジェクトとして作成されます。ただし、お客様の Terraform 設定のみが、今もなお databricks_database_instanceを使用してそれらを参照しています。既存のプロビジョニング済みインスタンスも、2026年6月から自動的にオートスケールにアップグレードされます。どちらの場合も、Terraform構成の更新ステップは同じです。以下の「インスタンスがオートスケール中であることを確認する」セクションを参照して、データベースインスタンスが正常に移行されたかどうかを確認してください。

更新の仕組み

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

この変更には、2回のterraform apply呼び出しが必要です。1回はオートスケールのリソースを採用するため、もう1回はプロビジョニングされたリソースをTerraformステートから削除するためです。

プロビジョニングとオートスケールの概念的な違いについては、デフォルトAutoscalingを参照してください。このページでは、Terraform の構成更新のみを対象としています。

前提条件

始める前に、以下のものが必要です。

• Terraform 1.7 以降です。「import」ブロックと「removed」ブロックには、Terraform 1.7以降が必要です。
• プロジェクトに対するCAN MANAGE権限を持つ、OAuth マシン間（M2M）認証用に構成されたサービスプリンシパルOAuthを使用したDatabricksへのサービスプリンシパル アクセスの承認とプロジェクト権限の管理を参照してください。
• Terraform によって databricks_database_instance として現在管理されている、正常に移行された Lakebase Provisioned データベース インスタンスセットアップに子インスタンスが含まれる場合、本ガイドも対応しています。以下の「インスタンスがオートスケール中であることを確認する」セクションを参照して、データベースインスタンスが正常に移行されたかどうかを確認してください。

このページでは、databricks_database_instanceについて説明します。databricks_database_synced_database_tableとdatabricks_database_catalogはまだ対応していません。また、アプリをdatabricks_database_instanceからdatabricks_postgres_projectリソースに切り替えることにも対応していません。

インスタンスがオートスケールになっていることを確認してください。

Terraform の構成を更新する前に、データベースインスタンスのオートスケールへのアップグレードが完了したことを確認してください。ステップ2 の import ブロックは、アップグレードが完了した後にのみ存在するオートスケールプロジェクト、ブランチ、エンドポイントを採用します。

確認するには：

1. Lakebase アプリで Provisioned ページを開き、インスタンスを見つけて、インスタンスページに移動してください。
2. インスタンスページのバナーで、アップグレードが正常に完了したかどうかを確認します。
3. [オートスケール UI へ移動] をクリックしてください。オートスケールUIのプロジェクトページにいる場合は、「設定」をクリックします。リソース名を見つけ、リソース名入力フィールドの近くにある2つの四角をクリックして、オートスケールプロジェクトのリソース名をコピーします。これをTerraform importブロック内のリソースを参照するために使用します。

アップグレードがまだ完了していない場合は、完了するまでお待ちいただいてから続行してください。お急ぎのアップグレードをご希望の場合は、アカウントチームまたは Databricks サポートにお問い合わせください。

リソースマッピング

プロビジョニング済み	オートスケール
親 databricks_database_instance	databricks_postgres_project および暗黙的に作成される production ブランチ
親インスタンスの読み取り/書き込みエンドポイント	databricks_postgres_endpoint productionブランチ上のendpoint_id = "primary"と
親インスタンス HA（node_count、読み取り可能なセカンダリ）	productionエンドポイントのコンピュートgroup spec
子databricks_database_instance（任意）	databricks_postgres_branch branch_id が子インスタンスのものと等しい name
子インスタンスの読み取り/書き込みエンドポイント	databricks_postgres_endpoint 子ブランチにendpoint_id = "primary"を含む

すべてのプロビジョニングされたインスタンスは、そのオートスケール プロジェクト上でproductionという名前のブランチにマッピングされます。子インスタンスは例外です：そのbranch_idが子インスタンスのnameと等しい個別のブランチにマッピングされます。

プロジェクトIDは、**親**インスタンスのnameを小文字にしたものです。名前に大文字が含まれている場合でも、プロジェクトIDは小文字の形式となります。インポートする前に Databricks UI で確認してください。すべてのブランチインポートIDは、子ブランチに対しても、そのプロジェクトIDをプロジェクトセグメントとして使用します。

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

初期構成は以下のようになります。「my-instance」と「my-child」はプレースホルダーです。実際のインスタンスがすでに持っている名前を使用してください。ここでのルートインスタンスはHA（プライマリと読み取り可能なセカンダリ）です；お使いのインスタンスがそうでない場合は、node_count と enable_readable_secondaries を省いてください。

Hcl

terraform {
  required_providers {
    databricks = {
      source = "databricks/databricks"
    }
  }
}

resource "databricks_database_instance" "root" {
  name     = "my-instance"
  capacity = "CU_2"
  node_count                  = 2
  enable_readable_secondaries = true
}

resource "databricks_database_instance" "child" {
  name     = "my-child"
  capacity = "CU_2"
  parent_instance_ref = {
    name = databricks_database_instance.root.name
  }
}

ステップ 2 （適用 1）：オートスケール リソースを導入する

既存のプロビジョニング済みリソースと共に、新しいオートスケールリソースを追加します。既存の databricks_database_instance ブロックは構成内に保持してください。新しいオートスケールリソースは、それらの隣に配置されます。プロジェクトと両方のブランチはimportブロックを使用します。2つのエンドポイント（productionブランチと子ブランチ）は、エンドポイントが現在、標準のimportブロックをサポートしていないため、importブロックの代わりにreplace_existing = trueを使用します。terraform plan は、エンドポイントが「作成されます」と表示されます。これは移行目的の予期された動作です ― サーバー側で何も再作成されることはなく、リソースは安全です。

Hcl

# In Lakebase Autoscaling, the parent database instance is represented
# by a project plus an implicitly created "production" branch.
resource "databricks_postgres_project" "root" {
  project_id = "my-instance"  # use the ID from section "Confirm your instance is on Autoscaling"
  spec       = null
}

# Branch corresponding to the parent database_instance.
resource "databricks_postgres_branch" "production" {
  branch_id = "production"
  parent    = databricks_postgres_project.root.name
  spec      = null
}

# Branch corresponding to the child database_instance.
resource "databricks_postgres_branch" "child" {
  branch_id = "my-child"
  parent    = databricks_postgres_project.root.name
  spec      = null
  # spec = null is required during adoption. Setting any spec field causes
  # Terraform to write that value on apply. Fields like source_branch,
  # source_branch_lsn, and endpoint_type are immutable in Lakebase —
  # specifying them forces Terraform to replace (delete and recreate) the
  # resource instead of importing it cleanly. After adoption is complete
  # you can populate mutable fields (such as is_protected) to manage the
  # branch going forward. To look up the source branch, read it from
  # Branch.status.source_branch.
}

# The child branch's primary read-write endpoint.
# Pick one of the spec variants from the tabs below.
resource "databricks_postgres_endpoint" "child_rw_endpoint" {
  endpoint_id = "primary"
  parent      = databricks_postgres_branch.child.name
  spec = {
    endpoint_type = "ENDPOINT_TYPE_READ_WRITE"
  }
  replace_existing = true
}

# The production branch's primary read-write endpoint. Because the parent
# instance is HA, its HA carries over here as a compute `group` (see the
# "Preserving HA" note below). If your parent instance isn't HA, drop the
# `group` and `no_suspension` and keep only `endpoint_type`. If
resource "databricks_postgres_endpoint" "production_rw_endpoint" {
  endpoint_id = "primary"
  parent      = databricks_postgres_branch.production.name
  spec = {
    endpoint_type = "ENDPOINT_TYPE_READ_WRITE"
    no_suspension = true
    group = {
      min                         = 2
      max                         = 2
      enable_readable_secondaries = true
    }
  }
  replace_existing = true
}

# Import the project. Postgres resources use the canonical
# "projects/{project_id}" form as the import ID, where project_id is
# the resource name from section "Confirm your instance is on Autoscaling",
# with "projects/" prefix stripped off.
import {
  to = databricks_postgres_project.root
  id = "projects/my-instance"
}

# Import the production branch. The Provisioned parent always maps to
# a branch named "production" on the new project.
# Use the resource name from section "Confirm your instance is on Autoscaling",
# append "/branches/production" to it.
import {
  to = databricks_postgres_branch.production
  id = "projects/my-instance/branches/production"
}

# Import the child branch. Use the resource name from section
# "Confirm your instance is on Autoscaling", same as when importing
# the "production" branch above. The branch segment is the child instance's name.
import {
  to = databricks_postgres_branch.child
  id = "projects/my-instance/branches/my-child"
}

エンドポイントの spec については、以下のいずれかのバリアントを選択してください。

Only import the Autoscaling resources

既存のエンドポイントをそのまま採用してください。導入時にサーバーサイドでの動作に変化はありません。

Hcl

spec = {
  endpoint_type = "ENDPOINT_TYPE_READ_WRITE"
}

Use Autoscaling feature during the import

子エンドポイントを採用し、かつ同じterraform apply でそのオートスケール範囲をオーバーライドします。プラットフォームのアップグレード後、エンドポイントはすでにデフォルト範囲でオートスケールされています：CU_2 インスタンスから採用されたエンドポイントの最小 CU 8、スケールトゥーゼロはオフです。ここで制限を設定すると、個別の適用なしにそのデフォルト範囲を上書きし、スケールゼロを有効にすることができます。MINが8である理由と、最小値および最大値の選択方法については、コンピュートサイズを参照してください。

Hcl

spec = {
  endpoint_type            = "ENDPOINT_TYPE_READ_WRITE"
  autoscaling_limit_min_cu = 4
  autoscaling_limit_max_cu = 16
}

注記

高可用性を保持します。 上記のproductionエンドポイントは、親インスタンスのHAをコンピュートgroupとして引き継ぎます。minとmaxはインスタンスのnode_countと等しくなり、enable_readable_secondariesはインスタンスと一致します。HA エンドポイントはno_suspension = trueを設定する必要があります。そのため、HA エンドポイントはゼロにスケールすることもできません。

いずれの選択肢も1つのterraform applyです。

terraform applyを実行します。

ステップ3（適用 2）：Terraform ステートからプロビジョニングされたリソースを削除

オートスケールのリソースがデータベースを正しく管理していることを確認したら、Terraform のステートから元の databricks_database_instance ブロックを削除してください。lifecycle.destroy = falseと合わせてremovedブロックを使用することで、Terraformはデータを削除せずにプロビジョニング済みリソースの管理を停止します。

構成からdatabricks_database_instance.rootとdatabricks_database_instance.childブロックを削除します。その後、追加します:

Hcl

removed {
  from = databricks_database_instance.child
  lifecycle {
    destroy = false  # it is crucial to set destroy = false. Not doing so results in your database being deleted.
  }
}

removed {
  from = databricks_database_instance.root
  lifecycle {
    destroy = false
  }
}

terraform applyを実行します。

プランの出力では、次のような行が表示されます。

# databricks_database_instance.root will no longer be managed by Terraform, but will not be destroyed
# (destroy = false is set in the configuration)

予想通りです。データはとどまります。Terraformはプロビジョニング済みリソースの追跡を停止し、ステップ2で採用したオートスケールリソースを介してデータベースを管理します。

Postgresロールとデータベース

オートスケールリソースが設定に組み込まれると、databricks_postgres_role および databricks_postgres_database を介して、Terraform を使用して Postgres ロールとデータベースを今後作成および更新できます。既存のデータベースに既に存在するが、Terraformで宣言されていないロールとデータベースは削除されません。Terraformが破壊するのは、ステートで追跡しているリソースのみです。構成の更新前に存在していたロールとデータベースのインポートはまだサポートされていません。「databricks_postgres_role」 および 「databricks_postgres_database」 のリファレンス ページ、または完全な例については 「Terraformを使用した典型的なLakebaseプロジェクトのセットアップ」 を参照してください。

productionブランチとprimaryエンドポイントと同様に、すべてのオートスケールプロジェクトには暗黙的に作成されるロールとデータベースも存在します。

アップグレード後、何ができるようになりましたか？

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

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

これらの多くを組み合わせて使用する、本番運用に対応した完全なTerraform構成については、「一般的なLakebaseプロジェクトのTerraformセットアップ」を参照してください。

参照

• デフォルトAutoscalling
• Lakebase向けのTerraformを始めましょう
• databricks_postgres_project Terraform レジストリの