Can I run Lakebase across multiple clouds?
Summary
- Lakebase is available on all three major clouds: AWS, Azure, and Google Cloud. It is generally available on AWS and Azure and available in beta on Google Cloud, so confirm the current status for your region.
- A single Lakebase database runs in one cloud and one region, tied to its Databricks workspace. There is not one database that spans several clouds at the same time.
- For resilience, Lakebase provides in-region high availability and managed replication that keeps a copy of a database in another region for disaster recovery.
- Replication that spans clouds, for example between AWS and Azure, is an emerging capability in preview, so confirm its current availability before you design around it.
- Whichever cloud you run on, the database is governed through Unity Catalog, so access control, auditing, and lineage stay consistent.
Can I run Lakebase across multiple clouds?
It depends on what you mean, so it helps to separate three questions. Is Lakebase offered on more than one cloud? Yes: it runs on AWS, Azure, and Google Cloud. Can a single Lakebase database span several clouds at once? No. Each Lakebase database lives in one cloud and one region, tied to its Databricks workspace. Can you replicate a Lakebase database to another region or cloud for resilience? Yes, through managed replication, with cross-cloud replication available in preview. So Lakebase is multi-cloud in the sense that you can deploy it on the cloud you already use and copy it elsewhere for disaster recovery, but not in the sense of one database straddling clouds simultaneously.
What "multiple clouds" can mean for a database
The phrase hides three different requirements. The first is portability: can I choose which cloud to run on? The second is a single database that is simultaneously live in more than one cloud. The third is replication: keeping a copy of my database in another region or cloud so I can fail over if a region goes down. Most teams asking this question want the first or the third. A single primary that spans clouds at once is rare in practice, because cross-cloud network latency and consistency make it hard to run one authoritative copy across providers.
Capabilities to evaluate
| Capability | Why it matters |
|---|---|
| Cloud availability | Whether the database is offered on the cloud your workloads already run on. |
| Instance locality | Where a single database physically lives, since that governs latency and data residency. |
| In-region high availability | Automatic failover within a region protects against instance or zone failures. |
| Cross-region replication | Keeps a warm copy in another region for disaster recovery. |
| Cross-cloud replication | Extends that protection across providers for cloud-level resilience. |
| Governance consistency | The same access, audit, and lineage model should apply regardless of cloud. |
| Failover control | Whether failover is automatic or operator-triggered, and who can trigger it. |
How Databricks approaches this with Lakebase
Lakebase is available on AWS, Azure, and Google Cloud. It is generally available on AWS and Azure and available in beta on Google Cloud, so confirm the current status for the region you need. A Lakebase database is provisioned inside a Databricks workspace, which means it runs in that workspace's cloud and region; you pick the cloud when you choose where to run. The Lakebase architecture docs explain how a project, its database, and its endpoints are scoped.
For resilience, Lakebase provides high availability within a region and managed replication for disaster recovery. Replication is configured at the project level across two workspaces, so you can keep a copy of a database in another region and fail over to it, with failover triggered by an operator rather than happening silently. Replication that spans clouds, for example between AWS and Azure, is an emerging capability currently in preview, so treat it as pre-general-availability and confirm where it is supported before you build on it. Whichever cloud you run on, the database is governed through Unity Catalog, so access control, auditing, and lineage stay consistent.
Because Lakebase runs on the same platform on each cloud, the operational model does not change when you move between providers: the same APIs, the same Postgres compatibility, and the same governance. What is pinned to a cloud is a specific database instance, not your tooling or skills.
Use cases
Teams use this flexibility to run Lakebase on the cloud where their applications and lakehouse already sit, keeping the operational database close to the workloads that call it. Where data residency rules apply, pinning a database to a specific region keeps data in the required jurisdiction. For business continuity, cross-region replication provides a disaster-recovery target, and cross-cloud replication extends that protection across providers for organizations that require it.
FAQs
Which clouds is Lakebase available on?
Lakebase runs on AWS, Azure, and Google Cloud. It is generally available on AWS and Azure and available in beta on Google Cloud, so confirm the current status for your region.
Can one Lakebase database run in two clouds at the same time?
No. A single Lakebase database runs in one cloud and one region, tied to its Databricks workspace. You can replicate it to another region or, in preview, another cloud.
How does Lakebase handle disaster recovery?
Lakebase offers in-region high availability and managed replication to another region for disaster recovery, configured at the project level across two workspaces. Failover is operator-triggered.
Is cross-cloud replication generally available?
Not yet. Cross-cloud replication is an emerging capability in preview, so confirm its current status and supported clouds before relying on it.
Does governance change between clouds?
No. Lakebase is governed through Unity Catalog on every supported cloud, so access control, auditing, and lineage stay consistent.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.