General questions about Managed Service for Sharded PostgreSQL
-
What are the benefits offered by Managed Service for Sharded PostgreSQL?
-
When is Managed Service for Sharded PostgreSQL not a good fit?
-
When should I choose Managed Service for Sharded PostgreSQL over Yandex Managed Service for YDB?
-
How is Managed Service for Sharded PostgreSQL different from Neon?
-
How is Managed Service for Sharded PostgreSQL different from Citus/Vitess?
-
How do I get started with Managed Service for Sharded PostgreSQL?
What is Managed Service for Sharded PostgreSQL?
Managed Service for Sharded PostgreSQL (Sharded PostgreSQL) is a managed service for horizontal PostgreSQL scaling through automatic sharding. It functions as an intelligent proxy router that processes SQL queries and distributes them across shards based on defined rules called sharding keys. In addition, Managed Service for Sharded PostgreSQL:
- Uses high-availability clusters as the foundation for sharding to maximize reliability.
- Maintains cluster availability during migrations from monolithic to sharded architectures.
- Optimized for OLTP queries with minimal overhead.
Key features
- Sharding by value range or by hash: the router selects the target shard for each query.
- Compatibility with the PostgreSQL extended protocol enables out-of-the-box support for prepared statements and client libraries.
- Support for the session and transaction modes.
- Unlimited number of routers.
- Rebalancing, i.e., cross-shard data migration for even load distribution.
- Support for assigning multiple servers to a single shard, which enables the router to distribute read-only queries among replicas and automatically locate the master.
What are the benefits offered by Managed Service for Sharded PostgreSQL?
With Managed Service for Sharded PostgreSQL, you get the following benefits:
- Managed service: Out-of-the-box support for automated updates, monitoring, and backups.
- High availability: Automatic failover to replicas in case of failures.
- Dynamic rebalancing:
REDISTRIBUTE KEY RANGEcommand for data redistribution across shards. - Transaction support:
SESSIONandTRANSACTIONconnection management modes. - Resource monitoring, where the user retains control over load.
- Consulting services.
When should I use Managed Service for Sharded PostgreSQL?
Managed Service for Sharded PostgreSQL is ideal for scenarios that meet one or more of these criteria:
- Your data size exceeds 1 TB with no remaining options for vertical scaling.
- Your workload exceeds 20,000 queries per second, causing visible performance degradation.
- Data cooling is required (archiving old data while keeping it accessible).
- You need to automate an existing sharded infrastructure.
We recommend implementing sharding if your cluster has more than four hosts, more than 40 CPU cores, or disk size exceeding 600 GB. Early migration to Managed Service for Sharded PostgreSQL removes the added complexity of handling multi-terabyte datasets.
When is Managed Service for Sharded PostgreSQL not a good fit?
Managed Service for Sharded PostgreSQL is not suitable for:
- OLAP workloads (use Yandex MPP Analytics for PostgreSQL instead).
- Complex queries involving data from multiple shards, e.g., cross-shard JOIN operations.
Are JSONB and large objects supported?
Yes. Managed Service for Sharded PostgreSQL supports all native PostgreSQL data types, including JSONB. Note that large objects may affect network performance.
When should I choose Managed Service for Sharded PostgreSQL over Yandex Managed Service for YDB?
Managed Service for Sharded PostgreSQL enables you to solve the PostgreSQL scaling problem without changing the DBMS type.
Can a multi-host Managed Service for PostgreSQL cluster serve as a shard in Managed Service for Sharded PostgreSQL?
Yes. In Managed Service for Sharded PostgreSQL, a shard can be either a single-host or a multi-host Managed Service for PostgreSQL cluster.
Does it make sense to migrate high-performance PostgreSQL instances (e.g., 96 vCPUs) to Sharded PostgreSQL?
Yes, if your application is ready for sharding. Sharded PostgreSQL replaces a single high-spec host with multiple smaller instances, allowing you to scale resources horizontally and balance the load.
How is Managed Service for Sharded PostgreSQL different from Neon?
Neon decouples the compute and storage layers (similar to Amazon Aurora), but it is not a sharded solution and does not support horizontal scaling of clusters. Sharded PostgreSQL achieves true horizontal scalability through data and query sharding across independent PostgreSQL nodes.
How is Managed Service for Sharded PostgreSQL different from Citus/Vitess?
| Feature | Managed Service for Sharded PostgreSQL | Citus | Vitess |
|---|---|---|---|
| Performance compared to PostgreSQL | 10–30% lower | 15–40% lower | 20–50% lower |
| Protocol | Native PostgreSQL | PostgreSQL extensions | Proprietary |
| Rebalancing | Via REDISTRIBUTE KEY RANGE; cluster remains available for reads and writes |
Requires downtime | Via VReplication |
| Management | Full integration with managed databases | Manual administration | End-to-end setup |
| Reading from replicas | Automated | Via master only | Via VTGate |
| License | Open PostgreSQL license | GNU AGPLv3 with limitations | Apache License 2.0 |
How do I get started with Managed Service for Sharded PostgreSQL?
Create your first Managed Service for Sharded PostgreSQL cluster. For step-by-step instructions, see Getting started with Managed Service for Sharded PostgreSQL.
Before you begin, define your cluster specifications:
- Sharding type.
- Your cluster network.
- Availability zone for your cluster hosts.
- Number and class of hosts.
- Storage size (reserved in full during cluster creation).