High availability

Important

Lakebase Autoscaling is available in the following regions: eastus, eastus2, centralus, southcentralus, westus, westus2, canadacentral, brazilsouth, northeurope, uksouth, westeurope, australiaeast, centralindia, southeastasia.

Lakebase Autoscaling is the latest version of Lakebase with autoscaling compute, scale-to-zero, branching, and instant restore. For feature comparison with Lakebase Provisioned, see choosing between versions.

High availability pairs a primary read/write compute with one or more secondary compute instances distributed across availability zones. When the primary becomes unavailable, a secondary compute instance is automatically promoted and your application continues from the last committed transaction. Your connection string remains unchanged.

High availability topology showing two connection strings routing to the primary and secondary compute instances in separate availability zones, all reading from shared storage

How high availability works

A Lakebase endpoint is the database address your application connects to. A high availability endpoint exposes two connection strings:

Primary ({endpoint-id}.database.{region}.databricks.com) — your main read/write connection. Use this in every application that connects to your database. After a failover, it automatically routes to whichever compute is now primary.
Secondary ({endpoint-id}-ro.database.{region}.databricks.com) — only available when Allow access to read-only compute instances is enabled. Secondary compute instances exist primarily as failover standbys; enabling read access lets you additionally route read queries across them.

Both connection strings are available from the Connect dialog on your endpoint.

Behind these connection strings, a high availability endpoint always has exactly one Primary compute instance and one to three Secondary compute instances. The primary handles all read/write traffic. Secondary compute instances run in different availability zones and are promoted to become the primary in the event of a failure.

Each secondary compute instance has an Access setting that determines whether it also serves read traffic:

Secondary access	What it does
Read-only	Secondary compute instance serves reads via the `-ro` connection string and can be promoted as primary as needed
Disabled	Secondary compute instance is active and ready for failover, but doesn't serve read traffic

You control this with the Allow access to read-only compute instances setting on the endpoint, which you can access in the Edit compute drawer. When enabled, all secondary compute instances serve reads; when disabled, they are on standby for failover only. In both cases, compute hardware is already allocated and running: promotion requires no new provisioning, so your failover capacity is reserved regardless of demand in the availability zone.

Computes tab showing Primary (Read/Write) and three secondary compute instances (Read-only)

The Computes tab shows each compute instance's Role (Primary or Secondary), Status, and Access level at a glance.

AZ distribution

Lakebase distributes the primary and secondary compute instances across availability zones, reducing the risk that a single AZ failure affects both the primary and all secondary compute instances.

Autoscaling in high availability

All compute instances in a high availability configuration share the same autoscaling range. The maximum spread between your minimum and maximum CU is 8 CU, the same limit as standalone compute instances.

Secondary compute instances are always scaled to at least the same CU size as the primary, ensuring your database capacity stays consistent after a failover.

Scale to zero is not available for compute instances in a high availability configuration. You can manually pause all compute instances, but your endpoint will be unavailable while paused.

Secondary compute instances vs. standalone read replicas

Secondary compute instances and standalone read replicas are different features that can coexist on the same branch:

	Secondary compute instances	Standalone read replicas
Purpose	Failover + optional read offload	Read offload only
Added via	High availability configuration	Add Read Replica
Participates in failover	Yes	No
Connection string	`-ro` on the primary endpoint	Own separate endpoint
Sizing	Shared with primary (endpoint-level)	Sized independently

When you need both high availability and additional read capacity beyond what your secondary compute instances provide, you can combine both features on the same branch. See Read replicas.

Failover behavior

Automatic failover

Lakebase monitors primary compute health continuously. If the primary becomes unavailable, failover is triggered automatically.

Failover preserves all committed transactions.

Failover phases: Normal operation, primary unavailable after detection, failover in progress with promotion, then service restored with same connection string and no data loss

After failover, the primary connection string ({endpoint-id}.database.{region}.databricks.com) automatically routes to the newly promoted compute instance. Applications don't need to change their connection configuration, but existing connections are terminated during failover and must reconnect. Applications with retry logic handle this automatically.

Failover with read-only access enabled

When Allow access to read-only compute instances is enabled and a failover occurs, the promoted secondary becomes the new primary and stops serving reads. If you have two or more readable secondaries, read traffic on the -ro connection string continues at reduced capacity until a replacement is provisioned. If you have only one, reads are fully interrupted until the replacement is ready.

Connection strings

The Connect dialog shows both connection strings with their current compute status:

Compute option in Connect dialog	Connection string	Use for
`Primary (name) ● Active`	`{endpoint-id}.database.{region}.databricks.com`	All writes; reads that must hit the current primary
`Secondary (name) ● Active RO`	`{endpoint-id}-ro.database.{region}.databricks.com`	Read offload to secondary compute instances (only available when Allow access to read-only compute instances is enabled)

The primary connection string always routes to the current primary, including after a failover.

Each compute instance also has its own direct connection string, accessible from the Computes tab via the actions menu (⋮) on each row. Direct connections are intended for troubleshooting individual compute instances, not for application use. Direct connection strings are per-compute and may change when secondaries are added, removed, or promoted.