An analytics platform's database is write-bound rather than read-bound. The team adds read replicas and nothing improves. Why, and what should be done instead?

Why replicas do not help

Every write still goes to the primary, and replicas add work to it — the primary must ship the log to each replica. Adding replicas to a write-bound system makes the primary marginally slower and the bottleneck slightly worse.

The confusion arises because replicas are the standard answer to "the database is overloaded", which is true only when the overload is reads.

The diagnostic that separates them

Look at what the primary is spending time on: write-ahead log flush, index maintenance, lock waits and vacuum pressure indicate write-bound. Buffer misses, sequential scans and high query time on selects indicate read-bound. A team that cannot name which one it is should not be choosing a remedy.

What actually helps a write-bound event workload

• Batch the writes. Inserting a thousand events in one statement rather than a thousand statements is frequently a large improvement, because per-statement overhead dominates for small rows. This is usually the single biggest win in event ingestion and it requires no new infrastructure.
• Reduce index maintenance. Every index is a write amplifier. Analytics tables often carry indexes added for a query that no longer runs.
• Buffer through a queue, so ingestion spikes do not translate directly into database write spikes and the database sees a smoothed rate.
• Separate the ingestion store from the query store entirely. Event ingestion wants an append-optimised, column-oriented store; the application's operational data wants a row store. Forcing both into one database is the actual architectural error, and it is the one that a queue and batching only postpone.
• Partition by time, so writes concentrate in the newest partition and old partitions can be dropped wholesale rather than deleted row by row — deletion of old data is itself a large write load that teams forget to count.

The scaling answer, when it is needed

Shard by a key that distributes writes — usually the customer or project — which is also the right key for query isolation. Unlike the read-bound case, sharding is genuinely the answer for write-bound workloads, once the cheaper options are exhausted. But batching and separating the ingestion path come first, because they are days of work rather than quarters.