Sharded PostgreSQL is moving from a specialist architecture into the managed-cloud mainstream. For Indian CIOs managing rapid growth in payments, logistics, marketplaces and digital commerce, that shift raises a practical question: should the next capacity problem be addressed with a larger server, or is it time to distribute data and writes across multiple PostgreSQL machines?

The answer isn’t simply “shard when traffic grows.” Sharding creates a distributed topology that changes data modelling, transactions, observability, incident response, compliance and software delivery. It can remove the limits of a single machine. It can also turn routine database operations into organisation-wide engineering concerns. The decision must therefore start with evidence, not vendor momentum.

Why sharded PostgreSQL is gaining enterprise attention

Managed PostgreSQL has traditionally scaled through larger compute instances, storage improvements, connection pooling and read replicas. These measures remain effective, but they can’t expand write capacity indefinitely or remove maintenance pressure concentrated on one primary database.

Newer managed offerings are broadening the available options. Microsoft describes Azure PostgreSQL elastic clusters as a managed implementation of the open-source Citus extension, supporting row-based and schema-based horizontal sharding in a shared-nothing architecture. Applications can continue to use familiar PostgreSQL interfaces while data is distributed across worker nodes. Depending on data placement, the service can route a query to one node or parallelise it across multiple nodes, according to Microsoft’s elastic cluster documentation.

On 10 September 2026, PlanetScale introduced Neki in platform preview as sharded PostgreSQL, drawing on its experience operating large MySQL fleets. Neki places a PostgreSQL-compatible router between applications and independent shards while retaining the standard wire protocol, drivers, ORMs and a single connection string. PlanetScale explicitly warns, however, that production workloads should not run on the preview because the product is evolving and may include breaking changes, as explained in its Neki announcement.

This is credible evidence that sharded PostgreSQL is becoming easier to consume. It doesn’t mean every enterprise should adopt them.

Decision gate 1: Have simpler scaling options been exhausted?

Before adopting sharded PostgreSQL, CIOs need to distinguish sharding from native table partitioning. Partitioning divides a logical table into smaller physical tables within the same database system. Sharding distributes data across separate database instances or worker nodes.

PostgreSQL supports range, list and hash partitioning and automatically routes rows using a partition key. Its documentation says partitioning is normally worthwhile when a table exceeds the server’s physical memory, although the actual threshold depends on the workload. Partitioning can improve partition-selective queries, speed up bulk-data removal and reduce the VACUUM overhead associated with large deletions. These benefits are detailed in the PostgreSQL partitioning documentation.

A high-volume telemetry or order-history table may need better partitioning rather than sharded PostgreSQL. Similarly, read replicas can handle reporting, catalogue browsing and other read-heavy traffic, while connection pooling can keep session pressure under control.

The case for sharded PostgreSQL becomes stronger when production measurements reveal persistent constraints in one or more areas:

• Write throughput: the primary can’t sustain peak or projected writes without unacceptable latency.
• Storage growth: the data set is approaching practical limits for one instance or its maintenance processes.
• Operational windows: backups, index creation, VACUUM activity or schema changes can’t complete safely within available windows.
• Availability: one primary remains too large a failure or recovery domain despite replicas and automated failover.
• Growth economics: repeated vertical upgrades cost more than a carefully designed scale-out architecture.

PlanetScale identifies disruptive vacuuming and indexing, multi-hour backups, connection limits, schema-change windows and transaction-wraparound concerns as practical signs of single-machine stress. These are diagnostic signals, not an automatic instruction to adopt sharded PostgreSQL.

Decision gate 2: Can the business define a durable shard key?

The shard key is the most consequential design choice in sharded PostgreSQL. It determines where records live, which queries stay local and which operations must contact several shards. A poor key creates skew, hotspots and excessive distributed work. A strong one aligns data placement with the application’s most common transaction boundaries.

Potential domains differ by industry:

• Fintech: customer, account or merchant identifiers may preserve payment and ledger affinity.
• Logistics: tenant, shipper or operational-region identifiers may group shipments and events.
• Commerce: seller, tenant or order-affinity keys may keep catalogue, inventory and fulfilment operations together.

No candidate should be approved on the strength of an architecture workshop alone. Teams need to analyse production query traces and test cardinality, data skew, tenant growth, write concentration, seasonal peaks and the percentage of transactions that would cross shards. A merchant key, for instance, may look logical until a small number of major merchants account for most writes. We see this pattern with clients more often than architecture diagrams suggest.

Azure hashes distribution-column values and maps them to shard ranges, while metadata identifies the worker responsible for each range. Newly created tables or schemas aren’t automatically distributed, so users must deliberately select and configure row-based or schema-based distribution, according to Microsoft. Neki also requires customers to select a shard key and describe table grouping and distribution through topology configuration.

A sharded PostgreSQL proof of concept should benchmark local and cross-shard paths separately. Measure latency for primary-key reads, writes, joins, aggregations, batch processing and end-of-day reporting. The results should show not just whether the database scales, but whether the proposed key reflects actual business behaviour.

Decision gate 3: Are transaction boundaries understood?

Applications built for one PostgreSQL primary often assume that joins, uniqueness rules, foreign keys and multi-table updates happen within one transactional boundary. With sharded PostgreSQL, teams must review those assumptions table by table and workflow by workflow.

The safest design keeps frequently joined and transactionally related records together. A payment instruction, its state transitions and associated account records may require shard affinity. In commerce, an order and its line items are natural candidates for co-location, while a cross-seller marketplace report may be handled as a distributed analytical query or moved to a separate analytics platform.

Architecture teams should explicitly test cross-shard transactions, deadlocks, timeouts, retries, idempotency and partial failures. They must also document how global identifiers and uniqueness constraints work. Even when a platform supports distributed operations, those operations may have different latency and failure characteristics from single-shard transactions.

Application readiness is therefore as important as database capacity. If services depend heavily on arbitrary joins across all customers or tenants, the workload may need refactoring, data duplication or an analytical serving layer before sharded PostgreSQL delivers the expected benefit.

Decision gate 4: Can operations handle a distributed database?

Managed sharded PostgreSQL services reduce toil, but they don’t remove topology. Each Neki shard is described as a complete PostgreSQL cluster with one primary and at least two replicas across three availability zones. Its control plane coordinates monitoring, failover, resharding, schema changes and upgrades, while routers can scale horizontally or vertically. Azure elastic clusters can add nodes and rebalance data online without blocking running workloads, according to their respective product documentation.

Operational rules still apply. Microsoft currently limits DDL and cluster-wide operations to the coordinator-role node. This shows why managed sharded PostgreSQL still calls for updated runbooks, access controls and deployment pipelines.

CIOs should assess whether their teams can monitor shard skew, router health, replica lag, distributed query latency and rebalancing progress. Backup restoration, disaster recovery and failover tests must prove that the organisation can recover the entire service, not just an individual node. Cost models also need to account for routers, replicas, cross-zone traffic, observability, test environments and increased engineering effort.

Data residency is a topology-wide requirement

For Indian payment workloads, data residency can’t be assessed by checking only the primary database region. The RBI’s 6 April 2018 directive requires end-to-end data relating to payment systems to be stored only in India, with an exception allowing a foreign transaction leg to be stored abroad when required. The requirement covers service providers, intermediaries and third-party vendors and is intended to provide unfettered supervisory access, as stated in the RBI directive.

A sharded PostgreSQL assessment must therefore map every primary, replica, backup, router, metadata service, log stream, telemetry destination and support-access workflow. Teams should also examine encryption, key location, retention, deletion, incident response and vendor subcontractors. Selecting a cloud region is necessary, but it isn’t a complete compliance control on its own.

A staged decision framework for CIOs

Enterprises can reduce risk by treating sharded PostgreSQL as an evidence-led modernisation programme rather than a one-step migration:

1. Establish the baseline. Record write throughput, read latency, connection use, table growth, maintenance duration, replication lag and recovery performance.
2. Optimise the current platform. Test indexing, query tuning, connection pooling, partitioning, archival policies and read-workload isolation.
3. Model future demand. Estimate when current limits will be reached under realistic growth and peak-event scenarios.
4. Select candidate keys from traces. Score each key for balance, stability, locality, hotspot risk and cross-shard activity.
5. Run a representative pilot. Use production-like data volumes and test local queries, distributed queries, retries, failovers, backups and resharding.
6. Validate governance. Confirm residency, auditability, access controls, recovery objectives, vendor responsibilities and exit options.
7. Migrate incrementally. Start with a bounded service or tenant group instead of moving the entire transactional estate at once.

A sound executive decision brings together three findings: a proven single-node constraint, a viable shard key and an operating model capable of managing distributed failure. If any one of these is missing, the organisation should continue improving the simpler architecture while preparing for future scale.

How Glorious Insight can help

Glorious Insight helps enterprises evaluate and execute database-led cloud modernisation through IT consulting, digital transformation, Azure migration, custom application engineering, cybersecurity and managed services. Our teams can assess PostgreSQL bottlenecks, analyse shard-key candidates, modernise web and mobile applications, design Azure landing zones and build analytics or AI services that reduce pressure on transactional systems.

For organisations considering sharded PostgreSQL, this multidisciplinary approach connects database architecture with application refactoring, security, observability, data governance and ongoing operations. That alignment matters when scaling decisions simultaneously affect customer journeys, regulatory controls and business continuity.

Scale out only when the evidence supports it

Sharded PostgreSQL is becoming a realistic managed option for enterprises whose workloads have moved beyond the comfortable limits of one primary server. It is particularly relevant to high-growth fintech, logistics and commerce platforms with clear tenant or customer boundaries and sustained write-intensive demand.

Mainstream availability, however, doesn’t make sharding the default. Partitioning, read replicas, disciplined data lifecycle management and application tuning remain simpler and often more economical. The decisive question is whether horizontal distribution solves a measured constraint while preserving acceptable transaction behaviour, operational resilience and regulatory control. Indian CIOs who answer that question through production evidence, careful shard-key design and staged migration will be better placed to scale without replacing one bottleneck with a more complex set of risks.