How do Lakebase read replicas scale reads without duplicating database storage?

Summary

• Lakebase read replicas use a shared storage model where multiple read-only database instances access the same underlying data, avoiding the storage duplication that comes with traditional replication.
• The architecture relies on copy-on-write semantics at the page level: replicas share the same pages of data until a write operation occurs, at which point only the changed page is copied.
• This approach lets teams spawn instant, point-in-time read replicas for analytics, testing, or read-heavy workloads without the storage cost of full data duplication.
• Read replicas are particularly valuable for microservice architectures and CI/CD pipelines where temporary isolated database instances are needed without infrastructure overhead.

How do Lakebase read replicas scale reads without duplicating database storage?

Read replicas are a clever solution to a classic scaling problem: how do you handle surging read traffic without either duplicating all your data or overprovisioning a single database? Lakebase's approach uses a shared storage model powered by copy-on-write semantics. Multiple read-only database instances all access the same underlying data pages. When a write operation occurs, only the changed page is written to a new location, leaving the original page untouched for all other readers. This means you can spin up dozens of replicas without the storage penalty of traditional replication.

What is a read replica?

A read replica is an isolated, read-only copy of a database that can serve queries independently from the primary instance. The replica receives the same data but cannot accept write operations. In traditional databases, each replica duplicates the entire dataset, which is expensive at scale. Lakebase read replicas solve this by decoupling the data layer (shared) from the compute layer (per-replica), so multiple readers can work from one dataset.

Key capabilities to evaluate

When choosing a database with read replicas, teams should assess these factors:

Capability	Why it matters
Instant provisioning	Replicas should spin up immediately without long initialization; useful for ephemeral workloads.
Storage efficiency	Replicas should not copy the entire dataset; shared storage prevents cost explosion.
Point-in-time consistency	Replicas should reflect specific database snapshots, not just current state; essential for reproducible queries.
Isolated compute	Each replica should have its own query cache and connection pool, preventing one heavy query from affecting others.
Network locality	Replicas should locate near consuming clients to minimize latency.
Automatic promotion	A replica should become writable if needed, enabling failover or testing workflows.

How Lakebase read replicas work

Lakebase is built on Neon, a serverless Postgres engine that separates storage from compute. The storage layer is a versioned, copy-on-write log of all data pages. When you create a read replica, Lakebase allocates a new compute instance (a Postgres process) and points it to a specific version of the storage log. The replica can read any page, but all reads go through the shared storage layer. If a write happens on the primary, the storage layer creates a new page version; the replica continues reading from the old version until it advances.
This design means read replicas are instant: no data copy, no long initialization. A replica created at 2:00pm reflects the database state at exactly 2:00pm, even if the primary has changed. For teams testing code changes, this enables isolation: each test can have its own replica at a known snapshot, without interfering with production or other tests.
Lakebase also supports branching, which is a variant of read replicas: a named branch is a writable replica that starts from a point-in-time and can diverge from the primary. Branches are useful for feature development and experimentation without touching production data.

Use cases

Analytics and reporting: Point read replicas to historical snapshots; run heavy analytics queries without slowing down the application.
Continuous integration: Each CI test suite gets its own replica at a known schema version, ensuring tests run on identical data and can run in parallel without conflicts.
Multi-tenant isolation: Create per-customer read replicas for secure, isolated analytics without sharing the primary instance.
Feature testing: Branch the database at a stable point, test application changes against the branch, then discard if unsuccessful or merge if ready.

FAQs

Do read replicas stay in sync with the primary?

Read replicas reflect a specific point-in-time on the primary, not a continuously-synced live copy. Once created, a replica is independent; it doesn't automatically advance. This is intentional: point-in-time isolation is the key feature. If you want a live-syncing replica, you need traditional replication (a different feature), which does duplicate storage.

Can I write to a read replica?

No, read replicas are read-only by design. However, you can promote a replica to a writable branch, which makes it an independent copy that can accept writes. Promotion is permanent; the branch diverges from the primary.

How many read replicas can I create?

Lakebase allows unlimited read replicas. Since they don't duplicate storage, the only cost is the compute instance per replica. You pay for the CPU and memory of the replica's Postgres process, not for data duplication.