The history of Postgres sharding

Database sharding emerged as a way to distribute workloads once a single database server could no longer meet demand, with the term possibly originating in Ultima Online’s fictional “shards” of a world. MySQL gained an early advantage through the popularity of the LAMP stack and large-scale implementations at companies such as Facebook and YouTube, whose routing project evolved into Vitess. Postgres users instead initially relied on specialized in-house systems, including Skype’s function-based PL/Proxy and Instagram’s application-managed logical shards, before Citus introduced a more broadly available extension-based coordinator-and-worker model. Later proxy systems such as PgDog and managed distributed, Postgres-compatible databases including Spanner, CockroachDB, and Yugabyte offered differing approaches, but the account identifies trade-offs involving manual operations, routing bottlenecks, limited native Postgres behavior, unpredictable data placement, or reduced operational control. Neki is presented as a newer platform intended to combine explicit, operator-controlled sharding with actual Postgres clusters, horizontally scalable routers, a centralized topology definition, independent shard sizing, and managed functions such as backups, recovery, health monitoring, pooling, and schema changes.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.