Views Before Failovers

Figma split horizontal sharding into two steps. First they made the application logically sharded: DBProxy routed every read and write as though shards existed, but the "shards" were database views sitting on the one unsharded physical instance. Only later did they physically split tables onto separate hosts, with about ten seconds of partial write unavailability per primary.

Why run the logical step first, against views, on the machine that was already serving production?

It buys time to support cross-shard transactions in DBProxy before any data actually moves.

It exercises the entire shard-aware path, routing, rewriting, application queries, under real traffic, while a bad result is still a feature flag flip away rather than a failover to undo.

Views let Postgres reject writes that cross a shard key, so the database enforces the invariant the application is about to depend on.

Views serve reads from a snapshot, which drops load on the primary enough to make the later split safe.