The Lakebase release notes mark it generally available on Google Cloud as of 30 October 2026, and Databricks published the announcement on 2 November. For a GCP workspace in one of the five GA regions, we'd stop opening a side database for a new app, then start moving one existing write path.
The check we'd run per app #
We'd settle where each app's Postgres goes before anyone creates a project, because the project is locked to the workspace region and can't be the thing you fix later. This is that conversation written down. It models our check and isn't a Databricks API.
GA_REGIONS = {"us-east4", "us-central1", "us-west1", "europe-west3", "asia-southeast1"}
def where_postgres_goes(region, outside_clients_need_psc, search_must_be_ga, production):
"""One app on a GCP Databricks workspace, as of Lakebase GA on Google Cloud."""
if region not in GA_REGIONS:
return "keep the side database: no Lakebase project in this region"
if outside_clients_need_psc:
return "wait: Private Service Connect for outside clients is Beta"
if search_must_be_ga:
return "keep search elsewhere: Lakebase Search on Google Cloud is Beta"
return "Lakebase with HA on" if production else "Lakebase on one compute, scale to zero allowed"
assert where_postgres_goes("us-east1", False, False, True).startswith("keep the side database")
assert where_postgres_goes("us-east4", True, False, True).startswith("wait")
assert where_postgres_goes("europe-west3", False, True, False).startswith("keep search elsewhere")
assert where_postgres_goes("us-central1", False, False, True) == "Lakebase with HA on"We'd expect a hurried review to miss the first assertion: us-east1 isn't us-east4.
The order is the point. Region goes first because nothing after it applies without a project. Private connectivity goes second, because it's the security team's call and no amount of convenience overrides it. Search goes last. It matters most where an app or agent needs vector or keyword search.
Why we'd move a write path at all #
We'd move one for governance. Postgres features aren't the reason.
Lakebase puts an app's tables under Unity Catalog with the rest of the estate, so an access review covers one set of grants instead of two. That's the claim we'd test on the first write path we move, by listing who can read the table, from which network, and what the audit trail records when they do. If any of those three answers still needs a second tool, the side database hasn't really gone, and the second app waits.
Take, as a worked example, an order-status service on Cloud SQL in us-east4, with an hourly job copying its writes into the lakehouse. It's the write path we'd pick first, because it has one owner, one table that matters, and a sync job that exists only to copy it. We'd point its writes at a Lakebase project in the same region and run the grants review above. The copy job goes last, once a week has passed with nobody needing it.
What HA changes #
The five names in GA_REGIONS are the GA region list. Inside them, for production we'd turn high availability on and write the Lakebase SLA into the design doc: 99.99% on an HA endpoint, 99.9% on one compute. HA means giving up scale to zero, which isn't available on an HA endpoint. We'd pay that for anything a customer waits on, and keep an internal tool that sits idle most of the day on one compute.
Three reasons we'd still keep Cloud SQL #
No region, no project. There the not-just-Postgres chapter still holds, because the lakehouse doesn't replace a database that has to sit next to an application Lakebase can't reach yet.
Private connectivity is the one we'd expect to stop a migration. Private Service Connect for Lakebase keeps Postgres traffic off the public internet, but the release notes still call the path for outside clients Beta. Apps and Feature Store connectors inside the workspace don't need it. A Postgres driver on a regional hostname does, and where the VPC policy is absolute we'd wait.
Lakebase Search on GCP is still Beta too, and enabling it restarts every compute and can't be undone. So we wouldn't switch it on just to try it. An app or agent that needs production vector or keyword search stays elsewhere for now, or accepts Beta on purpose, in writing.
Before the first write path moves, we'd time branching and cold starts in the GCP region we actually run. A number measured on another cloud doesn't belong in a GCP design doc. We'd also give every personal branch an expiry, and set the restore window on purpose rather than inherit the default.