When to shard Postgres: later than you think

Sharded Postgres is getting a serious managed option, and the correct response for most teams asking when to shard Postgres is to postpone the question rather than accelerate it. A credible product arriving is an argument for waiting, not for starting. That sounds contrarian; it follows directly from what sharding costs and what the alternatives now do.

The product is Neki, PlanetScale's sharded Postgres, built by the team behind Vitess and available in platform preview. The company is explicit that it is not a fork of Vitess: Vitess works by leaning on MySQL's strengths and engineering around its weaknesses, so Postgres was architected from first principles alongside design partners at scale.

Why Postgres took nineteen years to get here

PlanetScale's own history of Postgres sharding is the most useful thing published on the subject this year, partly because it is candid about why MySQL got there first. The LAMP stack dominated the early 2010s, so the companies that hit scale first were on MySQL, and the tooling followed them. YouTube pulled its routing layer out of the application around 2010 and Vitess was the result. Facebook was serving over 100 million active users in 2008 on roughly 1,800 MySQL nodes.

Postgres got one-offs instead. Skype announced PL/Proxy to the Postgres mailing list in 2007, routing queries by defining SQL functions in a proxy database — which meant every new query pattern needed a new function written by hand. Instagram's roughly 30 million users outgrew a single EC2 Postgres instance in 2012, and the answer was logical sharding in the application, mapping thousands of logical schemas onto a few physical databases. Elegant, low-overhead, and entirely their own.

Citus was the first open-source Postgres sharding solution designed for wider adoption, started in 2011 as a fork and refactored into a pure extension in 2016. It centralised routing in a coordinator node, which is an improvement and also a bottleneck: your application either sends everything through the coordinator or tracks connection strings to each worker. Shard management and backups remain semi-manual. PgDog and Aurora Limitless improve on the architecture, and still leave resharding, schema changes and disaster recovery to the operator.

The other branch gave up on real Postgres. Spanner, published as a paper in 2012 and released as a service in 2017, hides sharding entirely and splits tables automatically. CockroachDB and Yugabyte take a similar approach. All three are Postgres-compatible rather than Postgres, which shows up as limited extension support, occasional SQL gaps, and performance that is hard to predict because data placement is hard to predict.

Explicit sharding is the design choice worth noticing

Neki requires explicit sharding, which in 2026 reads almost as a provocation. PlanetScale's argument is that explicit sharding makes cross-shard latency penalties something engineers can understand and plan around, while automatic sharding blurs the line and makes it impossible to tell when a table will split or how much performance will drop when it does.

Sharding is defined by a routing file called the data topology, so operators can evolve the scheme over time; each router holds only a cache of that topology, so routers scale horizontally and one connection string fronts the whole cluster. The underlying clusters are true Postgres, which is what buys extension support and predictable behaviour.

Whether you agree with that trade or not, it clarifies the decision. Automatic distribution is a database that hides a hard problem from you. Explicit sharding is a database that makes you own it, with better tools than you would have built. Neither is free.

When to shard Postgres: what to rule out first

Sharding is the most expensive architectural decision available to a team running a relational database. It changes how you write queries, how you run migrations, how you take backups, how you test, and what your on-call engineer has to understand at three in the morning. Most teams reach for it years before the data says they should, usually after one bad week.

Before it is even a candidate, these should be exhausted, in order of how often they turn out to be the actual answer.

1. Find the queries, not the load. In most systems we are asked to look at, a handful of queries account for the majority of database time, and at least one of them is missing an index or scanning a table it should be filtering. This is unglamorous and it is usually the whole problem.
2. Scale vertically. A single Postgres instance on current cloud hardware is far larger than most teams assume. Instagram's ceiling in 2012 was a single EC2 instance of that era; the equivalent today is a different category of machine.
3. Move reads off the primary. Read replicas solve read-heavy workloads outright, and the application changes are modest next to a shard key.
4. Partition before you shard. Native declarative partitioning handles large tables with a natural time or tenant boundary inside one instance, keeping every join local.
5. Move what does not belong. Analytics queries, audit logs, event streams and full-text search sitting in your transactional database are a common reason a primary is saturated, and each has a better home.

If all five are genuinely done and write throughput on a single primary is still the binding constraint, you have a sharding problem. That is a real situation and it does happen. It is just much rarer than the number of teams planning for it, and the gap between the two is where a lot of avoidable complexity gets built — the pattern behind most of what we describe as the true cost of poor software architecture.

The costs nobody puts in the business case

The parts of a sharded system that hurt are rarely the parts that appear in the proposal. Cross-shard joins either disappear from your query vocabulary or get reimplemented in application code, which is slower and now yours to maintain. Unique constraints and foreign keys stop being a database guarantee across shard boundaries. Schema migrations run N times instead of once, and a partial failure leaves shards at different versions. Backups and point-in-time recovery need to be consistent across the set, not per node. Test environments either replicate the topology, which is expensive, or do not, which means you find shard-specific bugs in production.

A good managed product removes a large share of that operational burden and none of the modelling burden. The shard key remains yours to choose, and choosing it wrongly is the failure that no amount of tooling recovers from cheaply, because the fix is redistributing data you are actively serving.

What a managed option actually changes

Here is why a maturing product argues for waiting rather than moving.

The historical reason to shard early was that sharding later was catastrophic. If the only route was building a routing layer and a resharding process yourself — the position every Postgres team was in from 2007 until recently — then a team that could see the wall coming had to start eighteen months out. The cost of being late was an emergency migration with no tooling.

Managed sharding changes the shape of that risk. When the migration can be bought rather than built, the penalty for deciding late falls, and the value of deciding early falls with it. You get to spend the intervening two years shipping product on a simple architecture instead of operating a distributed one, and you make the decision with real data about your access patterns rather than a forecast.

There is a caveat worth stating plainly. Neki is in platform preview, not a decade-old default, and picking a data layer means picking an operational dependency for the life of the system. Preview is the right moment to prototype and to talk to the vendor about your topology. It is not the moment to commit a production migration you could defer. The same reasoning applies to any migration of a system that is currently working: the question is never whether the new thing is better, it is whether the switch is worth doing now.

The decision that does pay off early costs nothing in infrastructure. Choose a shard key on paper before you need one. Work out whether your data has a natural tenant, customer or region boundary, and then stop writing queries that cross it casually. Teams that keep their access patterns shard-friendly can shard in months when the time comes. Teams that let every query join across everything need a rewrite first, whatever product they buy — and that rewrite, not the sharding, is what takes the year. We treat that as basic hygiene on any scalable architecture work, and it is the cheapest insurance in this entire discussion.

So the answer to when to shard is: later than you think, and only after the five checks above are honestly closed. If you are not sure which of them applies to your system, that is a diagnosis worth doing before it is an architecture decision, and we are happy to work through it with you.