Supabase vs Neon vs PlanetScale: Free-Tier Traps + Real Migration Cost (2026)

Two years ago the playbook was "host everything on a free PlanetScale Hobby plan." Then PlanetScale killed that plan in April 2024, and Neon and Supabase became the default free starts for Postgres, while Turso carved out a niche with serverless SQLite. Fast-forward to November 2026 and the map changed again — Neon is now part of Databricks, and Supabase announced it was acquiring Turso in October 2026 [ref: Turso acquisition blog post, 2026-10-02].

These free tiers fail in completely different ways. A free tier you "outgrow" is not one event; it's one of four very different bad days. This post breaks down the per-vendor facts, what literally happens the day you exceed each limit, and what a migration costs in hours — for the solo dev who can't afford a $0 → hundreds-of-dollars surprise jump.

TL;DR

• Supabase Free (500 MB DB, 5 GB egress) pauses your project after 1 week of inactivity — a trap for low-traffic apps, not busy ones. Exceeding 500 MB sends the DB read-only at 95% disk. No automatic backups: you own your supabase db dump.
• Neon Free (1 GB storage, 100 CU-hours per project, 5 GB egress) never pauses for inactivity — scale-to-zero handles that — but exhausted CU-hours suspend compute and full storage blocks writes until the next billing cycle or an upgrade. Data is never deleted.
• PlanetScale has no free tier. The Hobby plan was retired April 8, 2024 and never replaced; entry pricing starts around $5/month for dev workloads, Metal from ~$50/month.
• Turso Free (5 GB storage, 500M rows read, 10M rows written, 100 DBs) is generous but SQLite-shaped — exceeding limits means upgrading, since overage billing on Free doesn't exist. And since Oct 2026 Turso is joining Supabase.
• Postgres→Postgres migration is near-free: one pg_dump/pg_restore pass, minutes of downtime. MySQL→Postgres and SQLite→Postgres are the expensive ones — schema rewrites, boolean/enum conversions, driver changes.
• Realistic "graduated" spend for a solo dev: $15–25/month (Neon Launch small workload or Supabase Pro with spend caps), not $5.

Free-Tier Facts Table (Nov 2026)

	Supabase Free	Neon Free	Turso Free	PlanetScale
Price	$0	$0	$0	No free tier
DB storage	500 MB DB size per project	1 GB per project, 20 GB org total	5 GB total	—
Compute quota	Shared CPU · 500 MB RAM instance	100 CU-hours/project/mo, autoscale up to 2 CU	N/A (rows-based)	—
Egress / reads	5 GB egress + 5 GB cached egress	5 GB egress per project	500M rows read, 10M rows written	—
Other caps	2 active projects, 50k MAU, 1 GB file storage, 500k function invocations	10 branches, 6h history, 1 snapshot, 60k auth MAU	1-day PITR, community support	Entry ~$5/mo, Metal ~$50+/mo
Projects allowed	2 active (pause/unpause trick for more)	100 projects	100 databases	—
Backups	None automatic — docs tell you to run supabase db dump yourself	1 manual snapshot + 6h history (no scheduled backups)	1-day PITR window	Paid plans only
The signature trap	Pause after 7 days of low activity	Compute suspension on CU-hour exhaustion	Rows-read/written caps	Free tier doesn't exist

Sources: Supabase pricing and Supabase pausing docs, Neon pricing page (last updated 2026-10-31), Turso pricing page, PlanetScale Hobby deprecation FAQ and PlanetScale pricing.

What Happens the Day You Exceed

Supabase: the inactivity pause and the read-only cliff

Two separate bad days here.

Bad day 1 — your side project goes quiet. Supabase pauses Free projects after 1 week of insufficient database activity, and "insufficient" is vague on purpose — the docs say "a few user requests to the database each day" typically keeps a project alive, but a brochure site or weekend-only hobby app will trip it. You get a warning email roughly a week beforehand, then a confirmation. After pausing you have a 1-year restore window per Supabase's docs, full state preserved. The cost isn't data loss — it's your app throwing connection errors until someone clicks Resume. (The common workaround: a GitHub Actions cron that pings the DB daily.)

Bad day 2 — you actually run out of space. At 95% of the disk, Supabase flips the database into read-only mode per its database-size guide. Reads keep working; inserts and updates get rejected. The fix is Pro ($25/mo including 8 GB disk) or deleting data through whatever write window remains. Egress hitting 5 GB is softer — new transfers are blocked until the billing cycle resets.

Also worth saying twice: no automated backups on Free. Supabase's own docs recommend exporting via supabase db dump regularly and keeping off-site copies. If you never did, you're migrating with whatever you can dump that day.

Neon: the CU-hour meter and the write-block wall

Neon's free tier is the most generous and the most instrumented. It doesn't pause anything for inactivity — compute scales to zero after 5 minutes idle and cold-starts in "a few hundred milliseconds" (their words). A quiet Neon project on the Free plan stays alive forever, costing only the seconds it's awake.

But there's a monthly meter: 100 CU-hours per project. Running the floor-size 0.25 CU compute 24/7 burns ~180 CU-hours, so Free barely covers "always on" for one small project, and autoscaling can cap at 2 CU. When CU-hours run dry, or the 5 GB egress is exhausted, Neon suspends compute entirely until the next billing period or an upgrade — stated explicitly in Neon's pricing FAQ. Connection attempts fail rather than hang; data is intact.

Bigger than the CU-hour wall is the storage one: exceeding 1 GB per project (or 20 GB across the org) blocks writes — you can still read, query, and dump. Neon's guidance is a straight upgrade to Launch to lift it; they also offer credits to developers and startups, up to $100k via their Startup Program if you qualify. The escape hatch is clean regardless: Neon is vanilla Postgres, so pg_dump walks you out the door in under an hour for a small DB. The lock-in is pricing-tier shape, not data-format shape.

PlanetScale: the tier that never came back

If you're hoping for a free tier at PlanetScale right now, there isn't one. The Hobby plan was officially retired April 8, 2024 with no successor PlanetScale Hobby deprecation FAQ. Pricing today opens at roughly $5/month for single-node dev workloads and $50/month for Metal NVMe clusters — and Vitess-sharded MySQL is no longer the only option, since managed Postgres went GA in September 2025.

There is no "graduation event" to plan for: you start paid or you're not on PlanetScale. If your current DB is PlanetScale MySQL, the migration cost isn't pricing-tier math — it's the MySQL→Postgres translation below, or a switch to another MySQL host.

Turso: rows are your meter, and it just got absorbed

Turso's free tier is metered differently: 5 GB storage, 500M rows read, 10M rows written monthly, up to 100 databases (Turso pricing). For read-heavy personal apps that's a lot of headroom; with a chatty ORM doing N+1 queries it evaporates fast — 10M monthly writes is about 3.8 inserts/second sustained. Hitting a limit on Free means upgrading (overage billing only exists once you enable it on a paid plan).

The bigger 2026 fact: Turso announced on Oct 2, 2026 that it's joining Supabase Turso acquisition post. The post says the platform keeps running, Turso Database stays open source, and the "graduation path" leads to standard Postgres in the Supabase ecosystem. Not "Turso died" — more "Turso today is free-tier-shaped, tomorrow it's the same vendor as Supabase."

Migration Cost: Data-Out Friction per Engine

Postgres → Postgres: the easy case (Supabase/Neon/anything)

If both ends are Postgres — Supabase, Neon, Prisma Postgres, a bare RDS box — this is near-free:

# dump from source (Supabase example)
supabase db dump --data-only --file data.sql > dump.sql
# or the generic form
pg_dump -h <source-host> -U postgres -Fc -d postgres > dump.sql
# restore into destination
pg_restore -h <dest-host> -U postgres -d postgres --no-owner --no-privileges dump.sql

Everything travels: schema, types, indexes, sequences, extensions, function definitions. Real time for a solo dev on a <1 GB database: 20–40 minutes including connection-string swaps and a smoke test — the free-tier ceilings make the dataset smaller than most laptop backups.

CSV is the trap within the trap. CSV export gives you structure-free rows: NULL handling, date formats, encoding, and column ordering all become manual problems. Avoid it as the primary migration path.

MySQL → Postgres: the translation tax

Moving out of PlanetScale almost always means leaving MySQL, unless you pick another MySQL host. That's a schema-language problem, not a data-copy problem. Booleans live as TINYINT(1) in MySQL; Postgres wants BOOLEAN (values literal true/false, not 1/0). Enums, DATETIME precision, AUTO_INCREMENT → sequences, charset/collation defaults, and the ON UPDATE CURRENT_TIMESTAMP habit all need rewriting. Tools like pgloader automate part of this, but you'll still hand-review generated types and fix app-level SQL: backtick quoting, LIMIT dialect differences, NOW() semantics.

Realistic estimate for a small app (10–20 tables, <1 GB): a full working day, not an afternoon. That's your honest PlanetScale-out cost.

Turso/SQLite → Postgres: app-code rewrite is the real bill

Turso export is easy — it's SQLite underneath, and a turso db dump (or the file itself) gives you the whole database. The friction isn't data; it's that your application code speaks libSQL/SQLite — driver API, ? vs $1 placeholders, INTEGER primary keys that Postgres wants as identity columns, differences in ON CONFLICT support, and SQLite's loose typing vs Postgres' strict rules.

Budget granularly: the data move is under an hour, the schema rewrite is a same-day job with pgloader's SQLite mode or a hand-written CREATE script, and the driver/ORM changes are the piece that stretches into a multi-day refactor.

Which One for Which Workload

• Quiet side project that must stay reachable → Neon. No inactivity pause; scale-to-zero means silence costs nothing. Watch the 1 GB/project storage cap.
• Active hobby app using Auth + Storage + Postgres together → Supabase. Schedule a cron ping if traffic is thin, run scheduled supabase db dump for backups; graduation is one clean Pro ($25) block.
• Many isolated little DBs (per-tenant, per-experiment) → Neon Free (100 projects, separate quota each) or Turso Free (100 databases). Neon keeps the Postgres escape hatch; Turso locks you into SQLite-shape code.
• High-read, low-write, many small instances → Turso — 500M rows read/month for $0 is hard to beat — accepting its Oct 2026 Supabase orbit.
• Mission-critical or revenue-bearing → start paid from day one: PlanetScale (~$5/mo entry), Neon Launch, or Supabase Pro. Postgres→Postgres migration later costs an afternoon; MySQL→Postgres or SQLite→Postgres costs a day-plus of rewrite pain. Price that bill into your engine choice.

Wrap-up

• The trap isn't running out of resources — it's the mismatch in failure modes: Supabase punishes inactivity, Neon punishes compute-hours, Turso punishes rows, PlanetScale punishes optimism. Match your workload to the failure mode you can live with.
• Migration costs are asymmetric by engine: Postgres→Postgres ≈ under an hour with pg_dump, MySQL→Postgres ≈ a full working day of schema/type/SQL translation, SQLite→Postgres ≈ a multi-day app-code refactor. Choose your vendor now with that bill priced in.

Sources

• Supabase Pricing
• Supabase Project Pausing docs
• Supabase Database & Disk Size docs
• Supabase Database Backups docs
• Neon Pricing (last updated 2026-10-31)
• Neon Plans docs
• PlanetScale Hobby tier deprecation FAQ
• PlanetScale Pricing
• PlanetScale blog: Hobby retirement announcement
• Turso Pricing
• Turso: joining Supabase (2026-10-02)