# Amazon Aurora vs Supabase

Canonical: https://inetgeek.com/compare/amazon-aurora-vs-supabase/

Every value below is read from Amazon Aurora's and Supabase's own documentation. See https://inetgeek.com/methodology/ for how.

## At a glance

| Criterion | Amazon Aurora | Supabase |
| --- | --- | --- |
| Free tier | Yes — capped Free plan plus time-limited credits | Yes |
| Pricing model | Pay per use with no plan fee: instances plus storage plus I/O, or ACU-hours in serverless mode. AWS's own worked example prices serverless compute at $0.12 per ACU-hour on Aurora Standard and $0.156 on Aurora I/O-Optimized in US East (N. Virginia) — the difference being whether I/O is metered separately or folded into a higher compute and storage rate. Provisioned instances also offer Reserved Instance pricing, and usage may qualify for Database Savings Plans against a committed hourly spend. | Fixed monthly plan per organisation plus per-project compute, billed hourly by instance size |
| Regions | 34 AWS regions, the same list for the MySQL- and PostgreSQL-compatible editions. Counted from the two availability tables in Aurora's own docs, which publish the regions and no total. | 17 specific AWS regions across the Americas, Europe, Asia-Pacific and South America, plus broader 'general region' groupings that place the project on an available AWS region within an area. General regions do not support read replicas or API management. |
| Engine | MySQL- and PostgreSQL-compatible. Aurora is AWS's own engine rather than a hosted build of either, so compatibility is the claim being made — existing code, tools and applications are stated to work, which is not the same as being the upstream database. | PostgreSQL |
| Database branching | Limited — clones, not a branch workflow | Supported |
| Point-in-time recovery | Any point inside the backup retention period, so up to 35 days. Aurora's backups are continuous and incremental against the cluster volume rather than periodic snapshots plus log replay, which is why AWS states no performance impact while they are taken. | Point-in-time recovery is a paid add-on on Pro, Team and Enterprise, and needs at least a Small compute add-on alongside it. Worst-case recovery point is 2 minutes. Without it, restores go back only to a daily backup. |
| Read replicas | Supported — 15 per cluster, a quota AWS will not raise | Supported |
| Backup retention | 1 to 35 days. Unlike an RDS DB instance it cannot be set to 0 — Aurora backs the cluster volume up continuously and there is no way to turn that off. | Daily backups: 7 days on Pro, 14 days on Team, up to 30 days on Enterprise. Free projects get no automatic backups at all — Supabase tells free users to export their own data with the CLI. |

## Where they differ

### Pricing model

- Amazon Aurora: Pay per use with no plan fee: instances plus storage plus I/O, or ACU-hours in serverless mode. AWS's own worked example prices serverless compute at $0.12 per ACU-hour on Aurora Standard and $0.156 on Aurora I/O-Optimized in US East (N. Virginia) — the difference being whether I/O is metered separately or folded into a higher compute and storage rate. Provisioned instances also offer Reserved Instance pricing, and usage may qualify for Database Savings Plans against a committed hourly spend. ([source](https://aws.amazon.com/rds/aurora/pricing/))
- Supabase: Fixed monthly plan per organisation plus per-project compute, billed hourly by instance size ([source](https://supabase.com/pricing))

### Regions

- Amazon Aurora: 34 AWS regions, the same list for the MySQL- and PostgreSQL-compatible editions. Counted from the two availability tables in Aurora's own docs, which publish the regions and no total. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html))
- Supabase: 17 specific AWS regions across the Americas, Europe, Asia-Pacific and South America, plus broader 'general region' groupings that place the project on an available AWS region within an area. General regions do not support read replicas or API management. ([source](https://supabase.com/docs/guides/platform/regions))

### Engine

- Amazon Aurora: MySQL- and PostgreSQL-compatible. Aurora is AWS's own engine rather than a hosted build of either, so compatibility is the claim being made — existing code, tools and applications are stated to work, which is not the same as being the upstream database. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html))
- Supabase: PostgreSQL ([source](https://supabase.com/docs/guides/database/connecting-to-postgres))

### Database branching

- Amazon Aurora: Limited — clones, not a branch workflow ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html))
- Supabase: Supported ([source](https://supabase.com/pricing))

### Point-in-time recovery

- Amazon Aurora: Any point inside the backup retention period, so up to 35 days. Aurora's backups are continuous and incremental against the cluster volume rather than periodic snapshots plus log replay, which is why AWS states no performance impact while they are taken. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html))
- Supabase: Point-in-time recovery is a paid add-on on Pro, Team and Enterprise, and needs at least a Small compute add-on alongside it. Worst-case recovery point is 2 minutes. Without it, restores go back only to a daily backup. ([source](https://supabase.com/docs/guides/platform/backups))

### Backup retention

- Amazon Aurora: 1 to 35 days. Unlike an RDS DB instance it cannot be set to 0 — Aurora backs the cluster volume up continuously and there is no way to turn that off. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html))
- Supabase: Daily backups: 7 days on Pro, 14 days on Team, up to 30 days on Enterprise. Free projects get no automatic backups at all — Supabase tells free users to export their own data with the CLI. ([source](https://supabase.com/docs/guides/platform/backups))

## Which should you choose?

Pick Amazon Aurora if Teams on AWS who want a Postgres or MySQL cluster that can throw off a copy-on-write clone of production in minutes, keep up to fifteen readers behind it, and pause to nothing between bursts in serverless mode.

Pick Supabase if Teams who want Postgres plus auth, storage and generated APIs from one vendor on a fixed monthly bill, and who would otherwise assemble those pieces themselves.

Consider something else: Amazon Aurora — You want the upstream database rather than a compatible one, or a branch workflow rather than a clone. AWS documents cloning as a way to build a test environment, not as something you do per pull request.

Consider something else: Supabase — You want only a database. Much of the $25 covers a platform you may not use, and free projects are paused after a week of inactivity, which is not the same as scaling to zero.

## Documented by only one

- Entry paid plan: Supabase: $25/month for the Pro plan, including the first project and $10/mo of compute credits; additional projects from $10/mo
- Egress over allowance: Supabase: $0.09 per GB for uncached egress and $0.03 per GB for cached, charged only above the plan's quota. Egress restrictions clear at the next billing cycle, or immediately on upgrading or disabling the spend cap.
- Storage (entry plan): Supabase: 8 GB disk per project on the Pro plan; 500 MB on Free
- Included bandwidth: Supabase: 250 GB uncached and 250 GB cached egress a month on Pro and Team, pooled across Database, Auth, Storage and every other service as one Unified Egress Quota
- Managed connection pooling: Supabase: Supported
- Scales to zero: Amazon Aurora: Supported — serverless capacity mode only
- Connection limit: Supabase: 60 direct and 200 pooled connections on the Micro instance included with Pro; both scale with instance size
- When idle: Supabase: Free projects are paused after one week of inactivity and must be restored manually; paid projects are not paused
- Rewind in place: Amazon Aurora: Limited — Aurora MySQL edition only

## Questions this comparison answers

**Should I choose Amazon Aurora or Supabase?**

Pick Amazon Aurora if Teams on AWS who want a Postgres or MySQL cluster that can throw off a copy-on-write clone of production in minutes, keep up to fifteen readers behind it, and pause to nothing between bursts in serverless mode.
Pick Supabase if Teams who want Postgres plus auth, storage and generated APIs from one vendor on a fixed monthly bill, and who would otherwise assemble those pieces themselves.