# Amazon Aurora vs Neon

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

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

## At a glance

| Criterion | Amazon Aurora | Neon |
| --- | --- | --- |
| 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. | Usage-based with no minimum monthly fee on paid plans: $0.106/CU-hour compute and $0.35/GB-month storage on Launch, $0.222/CU-hour on Scale |
| Scales to zero | Supported — serverless capacity mode only | Supported |
| 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. | 8 AWS regions: N. Virginia, Ohio, Oregon, Frankfurt, London, Singapore, Sydney, São Paulo. A project's region is fixed at creation and cannot be changed. |
| 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. | History window of 6 hours up to 1 GB-month on Free, up to 7 days on Launch, up to 30 days on Scale |
| 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. | 1 day of history on paid plans by default and 6 hours on Free, configurable up to 7 days on Launch or 30 days on Scale. Neon notes that widening the window raises storage cost, so the ceiling is a paid choice rather than an included allowance. |

## 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/))
- Neon: Usage-based with no minimum monthly fee on paid plans: $0.106/CU-hour compute and $0.35/GB-month storage on Launch, $0.222/CU-hour on Scale ([source](https://neon.com/docs/introduction/plans))

### 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))
- Neon: 8 AWS regions: N. Virginia, Ohio, Oregon, Frankfurt, London, Singapore, Sydney, São Paulo. A project's region is fixed at creation and cannot be changed. ([source](https://neon.com/docs/introduction/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))
- Neon: PostgreSQL ([source](https://neon.com/docs/connect/connection-pooling))

### Database branching

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

### 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))
- Neon: History window of 6 hours up to 1 GB-month on Free, up to 7 days on Launch, up to 30 days on Scale ([source](https://neon.com/docs/introduction/plans))

### 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))
- Neon: 1 day of history on paid plans by default and 6 hours on Free, configurable up to 7 days on Launch or 30 days on Scale. Neon notes that widening the window raises storage cost, so the ceiling is a paid choice rather than an included allowance. ([source](https://neon.com/docs/introduction/point-in-time-restore))

## 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 Neon if Workloads that are idle most of the time, and teams who want a real database per pull request. Compute suspends after five minutes and storage is billed separately, so a staging branch costs almost nothing while nobody is using it.

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: Neon — You need predictable monthly billing. Usage pricing with no minimum fee cuts both ways, and a runaway query on an autoscaling compute is billed at the rate it ran.

## Documented by only one

- Entry paid plan: Neon: No fixed monthly fee. Launch is usage-based — Neon's own worked example puts typical spend at $15/month for intermittent load on 1 GB — so there is no entry price to compare, only a rate card. Recorded without a magnitude because a vendor's spend estimate is not a price.
- Egress over allowance: Neon: 5 GB per project included on Free; 500 GB per project included on Launch and Scale, then $0.10/GB
- Storage (entry plan): Neon: No included allowance on the Launch plan; storage is metered at $0.35/GB-month. The Free plan includes 0.5 GB per project.
- Managed connection pooling: Neon: Supported
- Connection limit: Neon: Scales with compute size: 104 direct connections at 0.25 CU (1 GB RAM), 419 at 1 CU, 2517 at 6 CU; up to 10,000 through the pooler
- When idle: Neon: Compute suspends after 5 minutes idle on Free and Launch, and can be disabled on Launch; configurable from 1 minute to always-on on Scale. The database is not deleted or paused — the next query restarts the compute.
- Rewind in place: Amazon Aurora: Limited — Aurora MySQL edition only

## Questions this comparison answers

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

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 Neon if Workloads that are idle most of the time, and teams who want a real database per pull request. Compute suspends after five minutes and storage is billed separately, so a staging branch costs almost nothing while nobody is using it.