Use Neon as your dev environment for AWS RDS: accelerate your workflow while reducing costs

Scaling Prisma applications with Neon read-only replicas

Learn what Neon read-only replicas are and how to leverage them to scale your Prisma applications.

Post image

In this guide, we’ll cover what read replicas are, how they work in Neon, and how to leverage them to scale your Prisma applications.

What is a read replica?

A read replica is a read-only synchronized copy of your primary database. It offloads read traffic from your primary database to improve performance and scalability.

Post image

Read replicas have several benefits:

  • Increased throughput: By distributing read requests among multiple read replicas, you can achieve higher throughput for both read-write and read-only workloads.
  • Workload offloading: Assign reporting or analytical workloads to a read replica to prevent any impact on the performance of read-write application workloads.
  • Access control: Provide read-only data access to certain users or applications that do not need write access.
  • Resource customization: Configure different CPU and memory resources for each read replica to cater to the specific needs of different users and applications.

Neon read-only replicas

In traditional Postgres, read replica data is synchronized using log-based replication. In this process, changes to the primary database are recorded in a Write-Ahead Log (WAL) and are then replayed on the read replicas to ensure data consistency. This process works differently in Neon due to its architecture, which separates storage and compute.

Read-only replicas in Neon are independent read-only compute instances that perform read operations on the same data as your read-write computes. Data is not replicated across database instances, and read requests are directed to a single source. 

Post image

Advantages of Neon’s read-only replicas 

Neon’s read-only replica feature includes the following advantages:

  1. Cost effectiveness: Since read-only computes read from the same source as your read-write compute, this means zero additional storage cost. Read-only computes also take advantage of Neon’s Autoscaling and Auto-suspend features, which enable efficient compute resource management.
  2. Data consistency: Read-write and read-only compute instances read data from a single source, ensuring a high degree of data consistency.
  3. Instant availability. When a read replica starts up, it is instantly up to date with your read-write primary. You do not have to wait for updates.

Creating a read-only replica

To create a read-only replica, you’ll need to sign up for Neon’s Pro plan. You can then select the branch where your database resides, click “Add Compute”, choose the read-only option, and configure the compute size.

Alternatively, you can use the Neon CLI to create a read-only replica by running the following command:

neonctl branches add-compute mybranch --type read_only

Connect to read-only replicas using @prisma/extension-read-replicas

Prisma Client doesn’t support read replicas out of the box. Fortunately, it can be extended to add functionality to your models, result objects, and queries or to add client-level methods. The Prisma team just released @prisma/extension-read-replicas, a Prisma Client extension that adds read replica support. Check out the launch blog post to learn more.

To connect to a Neon read-only replica using Prisma, first install the extension in your Prisma project:

npm install @prisma/extension-read-replicas

Next, extend your existing Prisma Client instance and point it to the Neon read-only replica:

import { PrismaClient } from '@prisma/client'
import { readReplicas } from '@prisma/extension-read-replicas'

const prisma = new PrismaClient()

You can also pass an array of connection strings if you would like to connect to multiple read replicas.

// lib/prisma.ts
const prisma = new PrismaClient()
     url: [

When your app runs, all read operations are sent to a database replica. If you specify multiple URLs, a read replica is selected randomly.

On the other hand, all write and $transaction queries are forwarded to the primary compute endpoint. 

If you would like to read from the primary compute endpoint and bypass read replicas, you can use the $primary() method on your extended Prisma Client instance:

const posts = await prisma.$primary().post.findMany()

This Prisma Client query will always be routed to your primary database to ensure up-to-date data.


Neon read-only replicas offer a robust solution to scale your Prisma applications efficiently. If you have any questions or feedback, please reach out to us in our community forum, we’d love to hear from you. 

Also, make sure to subscribe below if you would like to be notified of new content we publish on our blog.