Supabase moved read replicas to Infrastructure on 21 August 2026, and two live docs pages price disk throughput 10x

Summary. On 21 August 2026 Supabase moved read replica management out of Database then Replication and into Project Settings then Infrastructure, "next to compute and disk." The relocation is a two-minute change. The cost model it now sits beside is not. A read replica runs on the same compute size as the primary, gets a disk 1.25x the primary's size that is billed from the first byte, inherits provisioned IOPS and throughput, and takes its own $4 per month IPv4 address if the primary has one. Supabase's own worked example shows one Large project at $46.25-class rising to $427.06 per month once two Large replicas are added. Compute credits do not apply to replica compute, and read replicas are excluded from the Spend Cap. Meanwhile two live Supabase documentation pages price disk throughput at $0.95 and $0.095 per MB/s, a 10x gap that lands hardest on replicas because throughput is charged again for each one.

What changed on 21 August

The changelog entry is short and precise. "Read replica management now lives on Project Settings then Infrastructure, next to compute and disk. Database then Replication is for Pipelines destinations only." Old replica detail URLs redirect. Bookmarks carrying ?destinationType=Read+Replica on the Replication page now open the Infrastructure add-replica flow. The Management API is unchanged, and the entry claims "Read replica docs (updated for the new location)."

That claim mostly holds. The getting-started page, last modified 2026-08-21T03:04:25Z, now says "To add a Read Replica, go to the Infrastructure settings page in your project dashboard," and no docs page still points at the old location for replicas. Every remaining "Database then Replication" reference in the docs corpus belongs to Pipelines, which is correct.

The pointer is what broke. Three separate Supabase surfaces send readers to /docs/guides/platform/read-replicas as the setup guide: the read-replicas feature page ("Read Documentation"), the database replication guide ("Set up read replicas"), and the read-replicas-versus-bigger-compute blog post ("Read the full setup guide in the documentation"). That overview page contains no create instruction, no mention of Infrastructure, and no link to the getting-started page that carries the new path. The one page that was updated is the one nothing links to.

The cost model is the story

Placing replicas next to compute and disk is honest, because that is what a replica is. Supabase states it plainly: "Each is a dedicated database. You are charged for its resources, which are the following, and mirrored from the primary database: Compute, Disk Size, Provisioned Disk IOPS, Provisioned Disk Throughput, IPv4."

Three constraints do most of the damage to a budget.

Compute size is not yours to choose. "Read Replicas run on the same Compute size as the primary database," restated in getting-started as "All Read Replicas inherit the compute size of their Primary database." A 4XL primary means a 4XL replica at $960 per month.

Compute credits do not apply. Supabase's own FAQ answers it directly: "No, Compute Credits do not apply to Read Replica Compute." The $10 per month credit included with Pro and Team covers one Micro instance on the primary and nothing on the replica.

Neither replica compute nor IPv4 is capped. Both the read replicas usage page and the IPv4 usage page carry the same warning: these are "not covered by the Spend Cap."

Disk behaves the same way. "Launching a Read Replica creates an additional database with its own dedicated disk. You are charged from the first byte of provisioned disk for the Read Replica." The 8 GB allowance applies only to the primary. And the replica's disk is deliberately larger: "The disk size of a Read Replica is 1.25x the size of the primary disk to account for WAL archives."

Supabase publishes two worked examples that make the shape clear. A Pro project on Small compute with one Small replica: $25 plan, $15 primary compute, $15 replica compute, $1.25 replica disk, minus $10 credits, for $46.25. The same page's larger example, a Large project with 3,600 provisioned IOPS, 200 MB/s throughput, IPv4, and two Large replicas, totals $427.06 per month. The replicas are not an increment. They are most of the bill.

The 10x contradiction

Disk throughput has two published prices on live Supabase pages right now.

Supabase's own arithmetic settles it. In the read replica worked example, 200 MB/s provisioned minus the 125 MB/s baseline leaves 75 MB/s, and the line item reads $7.12. At $0.095 that is $7.125. At $0.95 it would be $71.25. The compute-and-disk page is the outlier, and it is the page a reader lands on when planning compute, which is exactly when they are also planning throughput.

This matters more for replicas than for a single database, because throughput is provisioned and charged per replica. A team sizing a three-database topology from the wrong page would overstate its throughput bill by roughly $192 per month at 200 MB/s, or understate it by the same amount reading in the other direction.

Can a replica be smaller than the primary? the docs and the blog disagree

The documentation says no, twice, in the two places a reader would check. The blog says yes, and builds a purchasing recommendation on it: "Choose a compute size (can match primary or be smaller for analytics-only workloads)," followed by "A 4XL primary with a 2XL replica ($960 + $410 = $1,370) costs less than an 8XL primary ($1,870) and may handle more read traffic." The features page hedges with "Select a compute size to match your workload."

If the documentation is correct, that entire cost argument is unbuildable, and a 4XL primary with one replica is $1,920 rather than $1,370. This is the kind of gap that turns into a variance conversation two invoices later. Verify it in the Infrastructure page before you plan around it, not after.

What else is worth knowing before you add one

The prerequisites are hard gates. A project must run on AWS, on at least a Small compute add-on, on Postgres 15 or later, and must not use legacy logical backups. Replica counts are tiered: "Projects on an XL compute add-on or larger can create up to five Read Replicas. Projects on compute add-ons smaller than XL can create up to two Read Replicas."

The Management API is still labelled beta on both endpoints, "[Beta] Set up a read replica" and "[Beta] Remove a read replica." It requires the infra_read_replicas_write permission on a fine-grained token, returns 402 with "This feature requires the Pro, Team, or Enterprise organization plan," and accepts 18 regions in its read_replica_region enum, including ap-south-1 and eu-central-1. Supabase's regions guide adds a constraint the changelog does not: "General regions aren't yet supported for read replicas or management via the API."

Replicas also block two operations outright. Project upgrades and data restorations both "require all Read Replicas for a project to be brought down before performing them," and must complete before replicas can be redeployed. If your disaster recovery runbook assumes a point-in-time restore can happen while replicas serve read traffic, it cannot.

One gap is worth naming as a gap rather than a number. Supabase's egress usage page enumerates database, auth, storage, edge function, realtime, shared pooler, log drain and cached egress, at $0.09 per GB uncached and $0.03 per GB cached. The word "replica" does not appear on it. Primary-to-replica replication traffic, including cross-region, is not priced anywhere we could find. Treat that as undocumented rather than free.

The engineering judgement

A read replica is a second full database at the primary's size, and it is the right tool when the read workload is genuinely separable and latency-bound, particularly for a global user base where the load balancer's geo-routing puts a database near the reader. It is the wrong tool when the actual problem is a slow query plan or an undersized primary, because it doubles the compute line rather than fixing the plan. The real cost is usually the second copy of everything, not the replica itself.

Teams already comparing managed Postgres options will recognise the pattern from our Neon versus Supabase serverless Postgres comparison, and teams running Supabase themselves should read it against the self-hosted Supabase Envoy gateway breaking changes. The billing dynamic is the same one we track in cloud FinOps for Indian engineering teams: the resources that escape the spend cap are the ones that produce the surprise.

India-specific considerations

The Management API accepts ap-south-1, so a Mumbai primary can carry Mumbai replicas, and the same 18-region enum allows a Singapore or Frankfurt replica for a distributed reader base. Two points deserve care under the Digital Personal Data Protection Act 2023. A read replica is a full copy of production data in whichever region you select, so a replica placed abroad for latency also places personal data abroad, and that decision now happens on a settings page next to compute rather than on a dedicated replication screen. Second, because Supabase does not document replication egress, cross-region replication cost for an India-to-elsewhere topology cannot be modelled from published figures. Ask before you provision.

FAQ

How eCorpIT can help

eCorpIT is an ISO 27001:2022 certified, CMMI Level 5 assessed engineering organisation in Gurugram, and our senior engineering teams size managed Postgres topologies against published pricing rather than dashboard defaults. We can model your Supabase or Neon read path, work out whether a replica or a query-plan fix is the cheaper answer, and set the spend controls that vendor caps do not cover. Talk to us via /contact-us/.

References

1. Supabase changelog, "Read replicas moved to Project Settings then Infrastructure", 21 August 2026

1. Supabase docs, Read Replicas overview

1. Supabase docs, Getting started with Read Replicas

1. Supabase docs, Manage your usage, Read Replicas

1. Supabase docs, Compute and Disk

1. Supabase docs, Manage your usage, Disk Size

1. Supabase docs, Manage your usage, Disk Throughput

1. Supabase docs, Manage your usage, IPv4

1. Supabase docs, IPv4 address add-on

1. Supabase docs, Manage your usage, Egress

1. Supabase API reference, Set up a read replica

1. Supabase pricing

1. Supabase features, Read replicas

1. Supabase docs, Regions

Last updated: 21 August 2026.