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

Summary

• Lakebase read replicas use streaming replication to distribute read queries without copying data to disk.
• Each replica streams changes from the primary database via write-ahead logging, caching only frequently accessed pages.
• This architecture decouples read scaling from storage, letting you add read capacity on demand.
• Read replicas are ideal for read-heavy workloads, reporting, and analytics without bloating infrastructure costs.

How do Lakebase read replicas scale reads without duplicating database storage?
Lakebase read replicas scale read throughput by having multiple Postgres instances stream and replay changes from a single primary database, without storing a full copy of the data on each replica. Each replica maintains its own buffer pool to cache frequently accessed pages, but the underlying data files remain on shared storage. This separation of compute from storage is the key to scaling reads without multiplying your storage footprint.

What are read replicas?

Read replicas are read-only database instances that stay in sync with a primary database by streaming changes in real time. Replicas actively replay transactions and remain consistent with the primary, providing a live copy rather than a point-in-time snapshot. In Postgres and Lakebase, this synchronization happens via streaming replication over the write-ahead log (WAL). A replica never accepts write queries; it only serves reads.

Key architectural patterns for read scaling

Pattern	How it scales reads	Storage impact	Best for
Streaming replicas	Each replica caches hot pages in memory; queries distribute across replicas	No duplication; shared storage	Read-heavy OLTP and analytics queries
Shared storage model	Replicas share the underlying data files; only buffer pools differ	Single copy of data on disk	Multi-region or failover scenarios
Query routing	Application or middleware directs reads to replicas, writes to primary	Minimal; no data duplication	Load-balanced OLTP workloads

How Lakebase approaches read scaling

Lakebase, powered by Neon's serverless Postgres architecture, implements read replicas through Neon's native streaming replication. When you create a read replica in Lakebase:

1. Replication starts immediately by streaming WAL records from the primary.
2. Each replica maintains its own buffer pool to cache the portions of data it accesses most frequently.
3. The actual data pages remain on shared storage, not duplicated on each replica's disk.
4. Compute autoscales independently from storage, so you can spin up replicas without growing your storage bill.

This approach is embedded in Neon's architecture. Neon's separation of compute (storage proxy) and storage (shared S3-like backend) means that adding a replica is purely a compute operation. You're not replicating terabytes of data; you're provisioning a new Postgres process that streams changes and maintains a working-set cache.

Use cases

Reporting and analytics – Route analytics queries to read replicas to avoid slowing down transactional workloads on the primary. Replicas stay consistent with the primary while absorbing the read load.
Multi-tenant or SaaS apps – Distribute read-heavy traffic across replicas. Each tenant's analytics or reporting features hit a replica, leaving the primary available for user-facing transactions.
Geographic distribution – Place read replicas in different regions to reduce latency for read-heavy clients without replicating your entire database footprint to each location.
Development and testing – Create replicas of production data for testing without doubling your storage costs.

FAQs

How fast is a read replica consistent with the primary?

Lakebase read replicas use streaming replication, so lag is typically in the single-digit milliseconds. The replica continuously streams and applies WAL records, keeping it nearly in sync with the primary. Exact lag depends on your workload; heavy write bursts may cause brief delays.

Can I promote a read replica to become the new primary?

Yes. If the primary fails, you can promote a replica to take over as the new primary. After promotion, the former primary can no longer accept connections (to prevent split-brain scenarios), and writes automatically route to the new primary.

What happens if I add too many read replicas?

Adding replicas increases your compute costs because each replica is a running Postgres process. Storage doesn't grow, but compute does. Monitor replica utilization and remove underused replicas to optimize costs.

Do applications need to know about replicas?

Applications need a way to route reads to replicas and writes to the primary. Most setups use a read/write split at the application layer (via a connection pool or ORM) or use a query router middleware that automatically directs queries based on their type.