Amazon Aurora vs Supabase
A comparison of Amazon Aurora and Supabase built from values read directly from each provider's own documentation, with the source recorded against every figure.
The short answer
- 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.
6 sourced criteria separate them:
- 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.
- Supabase: Fixed monthly plan per organisation plus per-project compute, billed hourly by instance size
- 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.
- 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.
- 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.
- Supabase: PostgreSQL
- Database branching
- Amazon Aurora: Limited — clones, not a branch workflow
- Supabase: Supported
- 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.
- 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.
- 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.
- 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.
Pick the criteria you care about. The chart counts how many of them lean toward each provider — the same read as scanning the bars below, just totalled for the ones you chose.
Amazon Aurora 0
Supabase 0
At a glance.
| Criterion | Amazon Aurora | Supabase |
|---|---|---|
| Pricing | ||
| 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 |
| Infrastructure | ||
| 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. |
| Data | ||
| 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.
- Supabase
- Fixed monthly plan per organisation plus per-project compute, billed hourly by instance size
Sources (2) →Sources ↓
- Amazon Aurora pricing — Amazon Web Services ↗
“Aurora charges for database instances and storage, along with any optional features you choose to enable. Aurora PostgreSQL and Aurora MySQL offer On-Demand and Reserved Instance pricing. [...] We want to calculate the compute costs of running this workload on Aurora serverless with the database cluster configured as Aurora Standard and Aurora I/O-Optimized in US East (N. Virginia). [...] 5 ACUs * $0.12 per ACU-hour * 30/60 hour $0.30 [...] 5 ACUs * $0.156 per ACU-hour * 30/60 hour $0.39”
Read 2026-09-09 · official pricing
- Pricing & Fees — Supabase ↗
“First project included. Additional projects from $10/mo. [...] Paid plans include $10/mo in compute credits, enough to cover one Micro instance.”
Read 2026-09-05 · official pricing
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.
Sources (2) →Sources ↓
- Regions and Availability Zones — Amazon Aurora User Guide ↗
“Aurora MySQL Region availability The following table shows the AWS Regions where Aurora MySQL is currently available and the endpoint for each Region. Region Name Region Endpoint Protocol US East (Ohio) us-east-2 rds.us-east-2.amazonaws.com HTTPS US East (N. Virginia) us-east-1 rds.us-east-1.amazonaws.com HTTPS [...] Aurora PostgreSQL Region availability”
Read 2026-09-09 · official docs
- Available regions — Supabase Docs ↗
“Each Supabase project is deployed to one primary region. [...] General regions deploy to an available AWS region within that broader area, which may not match a specific jurisdiction. For example, the "Europe" general region includes London and Zurich, which are not EU member states. Region selection is a data-location control, not proof of regulatory compliance. [...] General regions aren't yet supported for read replicas or management via the API.”
Read 2026-09-05 · official docs
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.
- Supabase
- PostgreSQL
Sources (2) →Sources ↓
- What is Amazon Aurora? — Amazon Aurora User Guide ↗
“Amazon Aurora (Aurora) is a fully managed relational database engine that's compatible with MySQL and PostgreSQL. [...] The code, tools, and applications you use today with your existing MySQL and PostgreSQL databases can be used with Aurora.”
Read 2026-09-09 · official docs
- Connect to your database — Supabase Docs ↗
“The session mode connection string connects to your Postgres instance via the Shared Pooler (Supavisor).”
Read 2026-09-05 · official docs
Database branching
- Amazon Aurora
- Limited — clones, not a branch workflow
- Supabase
- Supported
Sources (2) →Sources ↓
- Cloning a volume for an Amazon Aurora DB cluster — Amazon Aurora User Guide ↗
“Aurora uses a copy-on-write protocol to create a clone. This mechanism uses minimal additional space to create an initial clone. [...] Aurora cloning is especially useful for quickly setting up test environments using your production data, without risking data corruption.”
Read 2026-09-09 · official docs
- Pricing & Fees — Supabase ↗
“Branching [...] $0.01344 per branch, per hour”
Read 2026-09-05 · official 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.
- 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.
Sources (2) →Sources ↓
- Backing up and restoring an Aurora DB cluster — Amazon Aurora User Guide ↗
“Aurora automated backups are continuous and incremental, so you can quickly restore to any point within the backup retention period. No performance impact or interruption of database service occurs as backup data is being written.”
Read 2026-09-09 · official docs
- Database Backups — Supabase Docs ↗
“Point-in-Time Recovery (PITR) allows you to back up a project at shorter intervals, giving you the option to restore to any chosen point with up to seconds of granularity. [...] Pro, Team and Enterprise Plan projects can enable PITR as an add-on. Projects that want to use PITR must also use at least a Small compute add-on to ensure smooth functioning. [...] in the worst case scenario, PITR achieves a Recovery Point Objective (RPO) of two minutes.”
Read 2026-09-05 · official docs
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.
- 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.
Sources (2) →Sources ↓
- Backing up and restoring an Aurora DB cluster — Amazon Aurora User Guide ↗
“Aurora backs up your cluster volume automatically and retains restore data for the length of the backup retention period. [...] You can specify a backup retention period from 1–35 days when you create or modify a DB cluster.”
Read 2026-09-09 · official docs
- Database Backups — Supabase Docs ↗
“We automatically back up all Pro, Team, and Enterprise Plan projects on a daily basis. [...] Pro Plan projects can access the last 7 days of daily backups. Team Plan projects can access the last 14 days of daily backups, while Enterprise Plan projects can access up to 30 days of daily backups. [...] We recommend that free tier plan projects regularly export their data using the Supabase CLI db dump command and maintain off-site backups.”
Read 2026-09-05 · official docs
When these numbers change, hear about it. Sources are re-checked monthly; a repricing goes out as a short note.
Which should you choose?
Choose 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.
Editorial · Palash Bagchi · approved
Choose 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.
Editorial · Palash Bagchi · approved
Consider something else if…
- 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.
- 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.
These criteria are published by one provider and not the other. An absence here means we have not found a source, not that the feature is missing.
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.