What is the difference between Lakebase high availability and Lakebase cross-region disaster recovery?

Summary

• High availability (HA) is a configuration that keeps your database running continuously within a single region, even if individual servers fail; it minimizes downtime in normal operations.
• Cross-region disaster recovery (DR) is a configuration that replicates your database to a different geographic region so that if an entire region becomes unavailable (due to data center failure, regional outage, or disaster), you can fail over to the standby region.
• HA protects against server/node failures; DR protects against regional disasters and large-scale infrastructure failures.
• HA typically has recovery time objectives (RTO) measured in seconds to minutes; DR RTO is typically minutes to hours, depending on replication lag and failover automation.
• Lakebase provides both: automatic failover within a region for HA, and asynchronous replication to a standby region for DR.

What is the difference between Lakebase high availability and Lakebase cross-region disaster recovery?

High availability and disaster recovery are two complementary strategies for keeping your database operational. High availability (HA) ensures your database survives component failures within a region: a node crashes, a disk fails, or a network card goes down, but your application stays online. Disaster recovery (DR) ensures your database survives catastrophic events that affect an entire region: a data center fire, a major network outage, or a region becoming inaccessible. Understanding the difference is essential for architecting reliable systems: HA handles common failures; DR handles rare, large-scale ones.

What is high availability?

High availability means your database stays online even when individual servers or components fail. Technically, this is achieved by running multiple copies of your database across different servers or availability zones within the same region. If one server fails, the database automatically fails over to another copy, often so quickly that client applications don't notice the outage. HA is about eliminating single points of failure at the component level. In Lakebase, HA means running your Postgres database across multiple servers within a single AWS/Azure/GCP region. If a server fails, standby servers detect the failure and promote one of the standby copies to primary. Recovery Time Objective (RTO) is typically seconds to a few minutes. Data loss is minimal because all copies are kept in sync or near-sync.

What is cross-region disaster recovery?

Disaster recovery means your database can recover from events that wipe out an entire region. A cross-region DR setup maintains a standby database in a completely different geographic region. If the primary region becomes inaccessible (due to a region-wide outage, data center fire, or other disaster), you manually or automatically fail over to the standby region. Because the standby is in a different region, it survives regional disasters. Cross-region DR typically uses asynchronous replication: changes are written to the primary, then replicated to the standby, but there's a slight lag. RTO is typically 15 minutes to an hour, depending on replication lag and failover automation. Potential data loss is measured in seconds or minutes, depending on replication frequency.

Key differences to evaluate

Aspect	High Availability	Cross-Region DR
Failure scope	Server/node/AZ failure	Entire region failure
Scope of protection	Within one region	Across regions
Typical RTO	Seconds to minutes	15 minutes to 1+ hour
Typical RPO	Near-zero (synchronous)	Seconds to minutes (asynchronous)
Replication	Synchronous (same region)	Asynchronous (across regions)
Cost	Low (shared infrastructure)	Higher (separate region + replication)
Common trigger	Automatic failover	Manual failover (or automated policies)
Data risk	Minimal	Minor (replication lag)

How Lakebase implements both

Lakebase provides high availability by default within a region: your database runs across multiple servers with automatic failover. If a server fails, a standby is promoted, and your application reconnects automatically. Most client applications won't even notice.
For cross-region disaster recovery, Lakebase offers standby database instances in another region that receive asynchronous replication from your primary. You define the replication frequency and can trigger failover manually or via automated policies. If your primary region becomes unavailable, you direct your application to the standby region. The standby is read-only until failover; after failover, it becomes the primary.

Operational considerations

HA: Enables continuous operation during routine maintenance, patching, and component failures. No action required from the operator unless a failure occurs. Costs are minimal because HA shares infrastructure within a region.
Cross-region DR: Requires planning: choosing a standby region, configuring replication, planning the failover procedure, and testing it regularly. Costs are higher because you're running a second database instance. Most organizations enable both: HA keeps them running day-to-day, and cross-region DR protects against worst-case scenarios.

FAQs

Do I need both HA and cross-region DR?

For most applications, yes. HA is table stakes for operational reliability. Cross-region DR is essential if your application serves critical operations (trading, compliance, payment processing). For non-critical applications, HA alone may be sufficient.

What is RTO and RPO?

RTO (Recovery Time Objective) is how long it takes to restore service after a failure. RPO (Recovery Point Objective) is how much data you're willing to lose (measured as a time window). HA has low RTO (seconds to minutes) and low RPO (near-zero). Cross-region DR has higher RTO and RPO because replication is asynchronous.

Can I test my cross-region DR without impacting production?

Yes. Lakebase allows you to test failover by spinning up a temporary database from a standby snapshot. This lets you validate your failover procedures and application behavior without affecting the primary.

How often should I test failover?

Minimum quarterly, more often if the database is mission-critical. Testing validates that the standby is receiving data and that your failover procedures work as expected.