When is switching databases the right call? Compare Uber and Instagram.

The two stories, stated precisely.

• Uber (2016) moved its core storage from PostgreSQL to MySQL, under its own Schemaless layer. Its engineering post lists the reasons: write amplification, inefficient replication across data centers, a replica data-corruption bug it hit during a primary promotion, MVCC trouble on replicas, and difficult major-version upgrades. The post also says Uber's experience was mainly with PostgreSQL 9.2. That caveat matters, because several of these issues were fixed or reduced in later releases.
• Instagram (2012) stayed on PostgreSQL and sharded it. It split its data into thousands of logical shards, implemented as Postgres schemas, and mapped them onto a much smaller number of physical servers. It also built 64-bit IDs that sort by time and carry the shard number inside them: a millisecond timestamp, a logical shard ID and a per-shard sequence.

These are not two answers to the same question. The posts were written four years apart, at different scale, and for different workloads. Uber's problem was update-heavy rows with many secondary indexes, replicated across data centers. Instagram's problem was spreading a fast-growing write load across many machines.

Why Postgres can amplify writes. Postgres MVCC never edits a row in place: an UPDATE writes a new row version. Its secondary indexes point at the physical location of a row version, so a new version can mean a new entry in every index on the table, and all of that goes into the WAL that replicas receive. In MySQL's InnoDB, secondary indexes store the primary key instead, so an update that doesn't touch an indexed column doesn't change the secondary indexes.

What weakens the "every update rewrites every index" claim: HOT. Postgres has had heap-only tuple (HOT) updates since 8.3, so this predates Uber's move. The current documentation says an update can skip new index entries when no indexed column is modified (summarizing indexes such as BRIN don't count) and the page holding the old version has enough free space for the new one. Then the new version is chained from the old one on the same page. You can make HOT more likely by lowering a hot table's fillfactor (the default is 100, meaning fully packed pages). You can measure it by comparing n_tup_hot_upd with n_tup_upd in pg_stat_user_tables. Uber's case was weak for HOT because its updates changed indexed columns on tables with many indexes, so HOT couldn't apply. That's a workload fact, not a universal Postgres rule.

What weakens the upgrade argument: logical replication. In 2016 Postgres replication was physical, meaning byte-level WAL, so a replica had to run the same major version as the primary. Upgrades needed pg_upgrade and downtime. PostgreSQL 10 (2017) added built-in logical replication, which publishes row changes and can feed a subscriber running a different major version. That makes near-zero-downtime major upgrades and cross-version migrations practical.

How I decide, in order.

1. Measure the pain. Name the metric, for example WAL volume per second, replica lag, p99 write latency or the HOT ratio. Then name the operation that causes it. "Postgres is slow" is not a reason.
2. Try fixes inside the engine. Drop unused indexes, avoid updating indexed columns, tune fillfactor, upgrade the version, and move to logical replication or partitioning.
3. Try changing the shape of the data on the same engine. Shard it (Instagram's route), split hot columns into their own table, or move append-only data to a log or event store.
4. Only then price a switch. Count dual writes or change data capture (CDC), backfill, verification, rollback, rewriting queries and tooling, retraining on-call engineers, and the new engine's own failure modes. Uber didn't just swap engines: it ran MySQL underneath Schemaless, its own sharded storage layer.
5. Migrate per workload. Move the one table or service with the measured problem, not "the company".

Logical sharding in detail (Instagram's pattern).

• Pick far more logical shards than you have servers today, so growth means moving shards, not re-hashing keys.
• Store the mapping from logical shard to physical host in configuration or a small directory service. Moving a shard is then copy, catch up, and flip the mapping.
• Put the shard ID inside the primary key, as Instagram's IDs do. Any service can then route a request without a lookup.
• Choose the shard key from the main access path, such as the user ID. Cross-shard queries, joins and transactions become application work, so design them out early.

What a senior answer sounds like. "I wouldn't treat Uber and Instagram as a vote on Postgres versus MySQL. Uber's post is honest that it describes 9.2 and a write pattern where HOT couldn't help. Instagram shows that the same engine scales a different workload with logical shards. Before migrating, I'd show the metric, rule out the in-engine fixes, and estimate the migration cost against the gain."

Alternate interview scenarios