The moment you introduce sharding, you give up cross-shard foreign keys, cross-shard joins, and globally consistent transactions. These are not edge-case features — they are the reason you chose a relational database in the first place. The question is not whether to shard, but how long you can defer it while staying healthy.
The connection pool problem at scale
The first thing that breaks as a Postgres instance grows is not disk I/O or query throughput — it is connection count. A vanilla Postgres instance handles around 200 concurrent connections before forking overhead becomes measurable. With 100 application pods each maintaining a pool of 10, you hit that ceiling before you write your first complex join.
Stratum Managed Postgres fronts every instance with a PgBouncer-based pooling layer running in transaction mode. This allows thousands of application connections to multiplex onto a small, healthy set of server connections — typically 80–120. The result: you can run 500-pod fleets against a single Postgres primary without connection exhaustion.
Read replicas and query routing
Stratum automatically provisions read replicas with sub-second replication lag for every Managed Postgres instance above the Starter tier. The platform's query router inspects each statement at the driver level:
- Any statement inside an explicit
BEGINblock is pinned to the primary for the duration of the transaction. - Read-only
SELECTstatements outside a transaction are routed round-robin across the replica fleet. - Writes (
INSERT,UPDATE,DELETE, DDL) are always routed to the primary. - A session-level hint (
/* primary */) overrides routing for read-after-write scenarios where replica lag is unacceptable.
At 10 TB with a read:write ratio of 9:1 (typical for analytics-heavy SaaS workloads), offloading reads to a 3-replica fleet reduces primary CPU by roughly 60 % and extends the single-instance ceiling significantly.
Storage and vacuum at 10 TB
Postgres's MVCC model produces dead tuples at a rate that scales with your write throughput. At 10 TB, autovacuum configuration is not optional — it is survival. Stratum applies a curated set of per-table autovacuum overrides based on observed write rate, and schedules full VACUUM ANALYZE runs during low-traffic windows. Storage is provisioned on a log-structured backend that reduces write amplification compared to a standard EBS-style block device, keeping I/O headroom available for query bursts.
One of our customers runs a 9.4 TB single-instance Postgres database serving 3,000 concurrent application connections through the pooling layer, with a p99 query latency of under 8 ms. They evaluated sharding twice and deferred it both times after seeing the replica routing numbers.
When you actually need to shard
Stratum's position is not that sharding is always wrong — it is that most teams reach for it before exhausting the single-instance playbook. The signals that sharding is genuinely necessary:
- Primary write throughput exceeds 100 k transactions per second sustained, and batching cannot reduce it.
- A single table exceeds 1 TB and partition pruning is no longer sufficient to keep query plans efficient.
- Regulatory requirements demand that certain tenants' data never share storage with other tenants.
If none of these apply, the right answer is almost always: add a read replica, tune your connection pool, and run EXPLAIN ANALYZE on your five slowest queries. You will likely buy another 18 months before the shard conversation becomes necessary.