This feature allows engineers to scale read-heavy Postgres workloads globally while isolating specialized tasks like analytics or vector search. By providing independent resource tuning for each replica, teams can optimize performance and costs without impacting the primary database.
Starting today, you can create dedicated read replicas for Postgres databases on PlanetScale. This has been a widely requested feature on our platform, and you now have full control over creating, sizing, and connecting to them.
Dedicated read replicas are additional Postgres instances that replicate asynchronously from the primary cluster.
A common use case for this is reducing read latency for a global set of clients. Your primary database cluster exists in one region (say, us-east-1), while dedicated read replicas are stood up in European data centers (eu-west-1 and eu-central). Read traffic for clients and customers in Europe can be directed to one of these nodes, speeding up the end-user experience.
In your PlanetScale dashboard, this looks like:
You may not require a globally distributed database, but dedicated read replicas are useful even within a single cloud region.
You can create one or more dedicated read replicas within the same region and create connection credentials targeting them individually, allowing you to control precisely which work each is doing. For example, you can have your primary set up to handle all writes and general OLTP traffic, a dedicated read replica for vector search with pgvector, and an additional replica to handle analytics and longer-running queries that you don't want impacting production.
You can create and manage dedicated read replicas from the "Clusters" page in the PlanetScale dashboard, the API, or the CLI.
Each replica may have different requirements for RAM, latency, and performance. You can configure the instance size and disk characteristics of every node, letting you tune them for each use case.
For example, above we can see the eu-read-node instance is running on an M-640 with 8 vCPUs, 64GB of RAM, and a fast local NVMe drive. The dublin-double is configured as two PS-320 instances, with storage options like disk size, IOPS, and throughput being configurable separately from the primary configuration.
Learn more about using dedicated read replicas and their limitations in the docs and give them a try on your database today.
Continue reading on the original blog to support the author
Read full articleThese updates bridge the gap between traditional Postgres and distributed sharding. With read-only replicas, Azure support, and massive performance boosts to bulk writes, Neki offers a scalable path for Postgres workloads without sacrificing SQL compatibility or developer experience.
This expansion allows Azure-based teams to utilize PlanetScale's managed database features with low latency. The technical implementation highlights sophisticated Kubernetes networking strategies to overcome cloud provider IP limitations at scale.
Sharding strategies that work at launch often fail under scale. Understanding how to migrate from tenant-based sharding to more granular keys is crucial for maintaining performance and enabling features like cross-tenant communication without incurring application downtime.
Logical replication slots are vital for data integrity in downstream systems. By blocking cutovers until slots are synced, PlanetScale prevents silent data loss in CDC pipelines, ensuring high availability doesn't compromise consistency for external analytics or search indexes.
