When PostgreSQL slows down, sharding the database across multiple machines is one option. However, deciding to split before confirming what is congested can complicate operations while leaving root causes untouched.
PlanetScale announced Neki on September 10, 2026. It distributes PostgreSQL across multiple shards with a router directing queries. However, official documentation reviewed as of September 20 notes it is in platform preview and explicitly states not to run production workloads.
Five pieces of information to gather first
Below is a suggested set of diagnostic items to organize prior to product comparisons. It is not a sequence of changes guaranteed to fix issues simply by following it.
| Checkpoint item | Target to investigate | Evaluation examples |
|---|---|---|
| Slow SQL queries | Call count, total duration, execution plan | Whether individual executions are slow or high frequency consumes time |
| Connection | Concurrent connections, waiting, pool settings | Whether connection wait times are confused with slow queries |
| Lock | Wait chains and long-running transactions | Whether write contention is the primary factor |
| Resources and maintenance | CPU, I/O, storage capacity, VACUUM, etc. | Whether machine or maintenance process constraints exist |
| How data is used | Filter conditions, joins, aggregations, data skew | By what unit operations can be partitioned |
pg_stat_statements provides a way to examine SQL execution statistics. While EXPLAIN inspects execution plans, EXPLAIN ANALYZE actually executes the statement. Avoid casually running heavy operations or update statements in production.
Smaller changes may be more appropriate than splitting
If only specific queries are slow, reviewing SQL or indexing is a candidate. If waiting for connections, inspect connection pool settings. If the goal is distributing read load, evaluate whether read replicas can be used. However, replicas entail replication lag and consistency considerations.
When dropping seemingly unused indexes, verify that the observation period was not too short and that they do not support constraints. Moving data solely because it is old does not guarantee targeted queries will speed up. In all cases, measure before and after changes under identical load conditions.
If opting to split, identify cross-shard operations
Partitioning by customer ID makes it easier to consolidate operations confined to a single customer, but queries, aggregations, and joins across all customers will still remain. Splitting does not necessarily prevent them from running, but execution methods, load, and transaction constraints must be reviewed.
In your evaluation document, document shard keys, expected data skew, cross-shard operations, resharding, disaster recovery, and migration plans for rollback. Rather than asserting "splitting cannot be undone," estimating rollback costs and procedures beforehand provides better guidance for decisions.
When evaluating Neki, formulate a plan to test using anonymized representative data and load conditions before introducing production data into preview environments. Vendor performance figures cannot be applied directly to your own workloads.
Official documentation was reviewed on September 20, 2026. Deploying Neki and benchmarking PostgreSQL performance were not conducted. This article outlines diagnostic and verification planning.
Please consult GleamHub regarding database bottleneck investigations and architecture reviews.
