**Read replicas** are separate, managed instances of your Render Postgres database that only allow read operations. As you write data to your primary instance, Render asynchronously replicates those changes to your read replicas:

**Render**  
Read/Write  
Read only  
Read only  
Your other  
services  
Primary  
instance  
Replica  
A  
Replica  
B

Use read replicas to reduce load on your primary database and make one-off queries safer. They're great for analysis tools that don't need to write data, or for running computationally expensive queries without affecting the performance of your primary database.

Read replicas always have the same compute plan and storage as their primary database and are billed accordingly.

**Want to enable logical replication with `CREATE PUBLICATION`?**  
See [Logical Replication with Render Postgres](/content/docs/postgresql-logical-replication/index.html).

## Requirements

For your Render Postgres database to support read replicas, it must:

- Have at least 10 GB of storage  
- Use a [compute plan](/content/docs/compute-plans?tab=postgres#all-plans/index.html) with at least 0.5 CPU  
  - If your database uses a [legacy instance type](/content/docs/postgresql-legacy-instance-types/index.html), it must use the **Standard** instance type or higher.

Any database that meets these requirements can have up to five read replicas.

## Setup

Go to your database's **Info** page in the [Render Dashboard](https://dashboard.render.com/) and click **Add Read Replica**:

A confirmation dialog appears. If you confirm, Render spins up the replica instance and starts copying over data from the primary instance. That's it! Your read replica should become available within a few minutes. If it takes longer, please reach out to our support team in the [Render Dashboard](https://dashboard.render.com/?contact-support).

After a read replica becomes available, you can connect to it just like you do your primary instance, using its [internal or external connection URL](/content/docs/postgresql-creating-connecting#connect-to-your-database/index.html).

## Replication lag

Changes to your primary database are synced to its read replicas after a short delay. This delay varies based on the current load on your primary instance. You can monitor this from the primary instance's **Metrics** page, under **Replication Lag**.

Because of this short delay, read replicas are best suited to use cases that don't require instant access to the most recent data possible.

## Read replicas vs. high availability

Read replica instances are different from a **standby** instance that's used for [high availability](/content/docs/postgresql-high-availability/index.html). Read replicas help decrease load on your primary instance, and they're safer for one-off and expensive queries. In contrast, a standby instance helps reduce downtime in the event of instance failure.