# Databricks Lakebase Postgres: GA on Google Cloud, and the Cloud SQL question

> Lakebase Postgres is generally available on Google Cloud. Five regions, an HA SLA, and what still keeps Cloud SQL in the picture.

By Andrey Taran, 10 November 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/lakebase-postgres-is-now-generally-available-on-google/

The [Lakebase release notes](https://docs.databricks.com/gcp/en/release-notes/lakebase/) mark it generally available on Google Cloud as of 30 October 2026, and Databricks [published the announcement on 2 November](https://www.databricks.com/blog/lakebase-postgres-now-generally-available-google-cloud). 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.

```python
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](https://www.databricks.com/blog/lakebase-postgres-now-generally-available-google-cloud), 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](https://docs.databricks.com/gcp/en/oltp/projects/manage-projects#region-availability). Inside them, for production we'd turn [high availability](https://docs.databricks.com/gcp/en/oltp/projects/high-availability) on and write the [Lakebase SLA](https://www.databricks.com/legal/sla/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.

```mermaid How an app on GCP Databricks reaches Postgres before and after Lakebase GA
flowchart LR
  A["Databricks on Google Cloud"] --> B["Cloud SQL or AlloyDB"]
  B --> C["Separate IAM and a sync job"]
  A --> D["Lakebase project in the workspace region"]
  D --> E["Unity Catalog grants on the same estate"]
```

## Three reasons we'd still keep Cloud SQL

No region, no project. There the [not-just-Postgres chapter](https://databricks.techfabric.com/guide/not-just-postgres/) 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](https://docs.databricks.com/gcp/en/oltp/projects/private-link) keeps Postgres traffic off the public internet, but the [release notes](https://docs.databricks.com/gcp/en/release-notes/lakebase/#private-connectivity-to-lakebase-is-now-available-on-google-cloud-beta) 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](https://docs.databricks.com/gcp/en/oltp/projects/lakebase-search) 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.

> **Our position**: On a GCP Databricks workspace in one of the five GA regions, we'd make Lakebase the default for a new app or agent that already depends on Unity Catalog data, and we'd start moving one existing write path off Cloud SQL or AlloyDB. We'd keep the side database where the region is missing, where Private Service Connect for outside clients is required and Beta isn't acceptable, or where search has to be generally available today.