Read Replicas
Deploy read-only databases across multiple regions, for lower latency and better resource management.
Read Replicas are additional databases kept in sync with your Primary database. You can read your data from a Read Replica, which helps with:
- Load balancing: Read Replicas reduce load on the Primary database. For example, you can use a Read Replica for complex analytical queries and reserve the Primary for user-facing create, update, and delete operations.
- Improved latency: For projects with a global user base, additional databases can be deployed closer to users to reduce latency.
- Redundancy: Read Replicas provide data redundancy.
About Read Replicas
The database you start with when launching a Supabase project is your Primary database. A process called "replication" keeps Read Replicas in sync with the Primary. Replication is asynchronous to ensure that transactions on the Primary aren't blocked. There is a delay between an update on the Primary and the time that a Read Replica receives the change. This delay is called "replication lag."
You can only read data from a Read Replica. This is in contrast to a Primary database, where you can both read and write:
| select | insert | update | delete | |
|---|---|---|---|---|
| Primary | ✅ | ✅ | ✅ | ✅ |
| Read Replica | ✅ | - | - | - |
Features
Read Replicas offer the following features:
Dedicated endpoints
Each Read Replica has its own dedicated database and API endpoints.
- Find the database endpoint on the project's Connect panel. Toggle between Primary and Read Replicas using the Source dropdown.
- Find the API endpoint on the API Settings page under Project URL. Toggle between Primary and Read Replicas using the Source dropdown.
If you use an IPv4 add-on, the database endpoints for your Read Replicas also use an IPv4 add-on.
Read Replicas only support GET requests from the REST API. If you are calling a read-only Postgres function through the REST API, make sure to set the get: true option.
Requests to other Supabase products, such as Auth, Storage, and Realtime, aren't able to use a Read Replica or its API endpoint. Support for more products will be added in the future.
Dedicated connection pool
A connection pool through Supavisor is also available for each Read Replica. Find the connection string on the Database Settings page under Connection String.
API load balancer
A load balancer automatically balances requests between your Primary database and Read Replicas. Find its endpoint on the API Settings page.
The load balancer enables geo-routing for Data API requests to automatically route GET requests to the database closest to your user ensuring the lowest latency. You can also send Non-GET requests through this endpoint, and they are routed to the Primary database automatically.
You can also interact with other Supabase services (Auth, Edge Functions, Realtime, and Storage) through this load balancer so there's no need to worry about which endpoint to use and in which situations. Geo-routing for Auth, Realtime, and Storage aren't yet available but are coming soon.
Due to the requirements of the Auth service, all Auth requests are handled by the Primary, even when sent over the load balancer endpoint. This is similar to how non-Read requests for the Data API (PostgREST) are exclusively handled by the Primary.
To call a read-only Postgres function on Read Replicas through the REST API, use the get: true option.
If you remove all Read Replicas from your project, the load balancer and its endpoint are removed as well. Make sure to redirect requests back to your Primary database before removal.
From April 4th, 2025, the routing behavior for eligible Data API requests changed:
- Old behavior: Round-Robin distribution among all databases (all read replicas + primary) of your project, regardless of location
- New behavior: Geo-routing, that directs requests to the closest available database (all read replicas + primary)
The new behavior delivers a better experience for your users by minimizing the latency to your project. You can take full advantage of this by placing Read Replicas close to your major customer bases.
If you use a custom domain, requests will not be routed through the load balancer. You should instead use the dedicated endpoints provided in the dashboard.
Querying through the SQL editor
In the SQL editor, you can choose if you want to run the query on a particular Read Replica.
Logging
When a Read Replica is deployed, it emits logs from the following services:
Views on Log Explorer are automatically filtered by databases, with the logs of the Primary database displayed by default. Viewing logs from other databases can be toggled with the Source button found on the upper-right part section of the Logs Explorer page.
For API logs, logs can originate from the API Load Balancer as well. The upstream database or the one that eventually handles the request can be found under the Redirect Identifier field. This is equivalent to metadata.load_balancer_redirect_identifier when querying the underlying logs.
Metrics
Observability and metrics for Read Replicas are available on the Supabase Dashboard. Resource utilization for a specific Read Replica can be viewed on the Database Reports page by toggling for Source. Likewise, metrics on API requests going through either a Read Replica or Load Balancer API endpoint are also available on the dashboard through the API Reports page
We recommend ingesting your project's metrics into your own environment. If you have an existing ingestion pipeline set up for your project, you can update it to additionally ingest metrics from your Read Replicas.
Centralized configuration management
All settings configured through the dashboard will be propagated across all databases of a project. This ensures that no Read Replica get out of sync with the Primary database or with other Read Replicas.
Pricing
For a detailed breakdown of how we calculate charges, read the Manage Read Replica usage guide.