[ruslantalpa]

Changes

Add the postgres_data_apis resource (Private Preview). It enables and configures the Data API (PostgREST) of a Lakebase Postgres database:

resources:
  postgres_data_apis:
    app:
      parent: ${resources.postgres_databases.app_db.name}
      db_schemas: [public]
      db_max_rows: 1000
      jwt_cache_max_lifetime: 300s

• One Data API per database. Its ID is {parent}/data-api; changing parent recreates it. Removing the resource turns the Data API off; the database and its data are unaffected.
• The serving URL is status.url; reference it as ${resources.postgres_data_apis.<key>.status.url}. It is a stable output field: it is built from the read-write endpoint host, the workspace and the database name, so an in-place update of the Data API cannot change it, and the reference resolves without planning a no-op update of the resources that use it.
• Durations such as jwt_cache_max_lifetime use the protobuf seconds format, for example 300s.
• Create, update and delete wait on long-running operations. Update sends the configured spec with update_mask=spec.
• spec is INPUT_ONLY, so GET does not return it. DoRead fills the remote spec from status, which reports every setting in effect, so bundle plan detects out-of-band changes and bundle deployment bind applies the configured spec on the next deploy. The generated spec:input_only rules are dropped (apitypes.yml: postgres_data_apis: null) and every spec field is a hand-written backend_default, so a field the config omits is left to the server.
• Status omits a bool that is false and was never set, so the bool fields are forced on the remote side.
• A field removed from the config keeps its last value on the server: update_mask=spec merges, and per-field clearing is not used because clearing some fields currently leaves the Data API unable to serve requests. The removal plans one no-op update; the next plan is clean.
• Labelled Private Preview to match the API's launch stage (the other postgres_* resources are Beta), so it is not suggested in the JSON schema and not exposed in PyDABs yet.

Why

Lakebase users already manage projects, branches and databases with bundles and want to manage the Data API alongside them. The API is at Private Preview.

Notes for reviewers:

• Like every other postgres_* resource, this one waits on its operation inline in create, update and delete, because the operation ID isn't persisted.
• Registering the new type with the deployment metadata service is a separate server-side change. Until it is deployed, deploys with experimental.deployment_history enabled reject this resource type, so the cloud acceptance cells that run with deployment history on (DMS=true) will fail. Deploys without it are unaffected.
• Cloud coverage: the resource acceptance tests run on cloud (AWS only, like the siblings); the invariant and bind tests are local-only, like the siblings. A manual live run against a dev workspace covered the full lifecycle.
• jwt_role_claim_key and jwt_cache_max_lifetime are exposed because the API accepts them. Their runtime behaviour is still evolving at Private Preview; happy to hide them if you prefer.

Tests

• Acceptance tests against the local test server: basic, update, recreate, out-of-band, bind, and url_reference (a job parameter that references status.url resolves on the first deploy, and an in-place update of the Data API plans no update of the job). The test server's Data API fake mirrors the real API's defaults, status.url, merge-on-update semantics, and error codes and messages.
• Invariant config covering strings, lists, bools (true and an explicit false), a duration and an enum: no drift, removal of every optional field converges, delete/destroy idempotent.
• Unit tests for the status-to-spec mapping and the fake.
• Manual run against a dev workspace with a CLI built from this branch: deploy, serving through the Data API URL with a service principal token, a job parameter referencing status.url resolved on the first deploy, update (row cap applied, job not updated, next plan clean), removed field (value kept), out-of-band change detected and reverted, bind of an existing Data API applied on deploy, destroy (Data API off, data intact).

This pull request and its description were written by Isaac.

[github-actions]

Thanks for the contribution! This pull request was opened from a fork.

If you're a member of the Databricks organization, please request access to the cli-contrib team and open your pull request from a branch in this repository instead of a fork — fork PRs don't run integration tests automatically and have reduced CI access.

If you're an external contributor, no action is needed; a maintainer will review your pull request.

[github-actions]

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

• PR number: 7139
• Commit SHA: c30a3682aaf1dbabae0c5e7209300ba0a524c4e3

Checks will be approved automatically on success.