Supabase alternatives: what to use when the meter stops making sense

Supabase is a good product. It bundles Postgres, auth, storage, realtime, and edge functions behind one signup, and for a first version of an app that bundle is worth more than any individual piece of it. Most people asking for an alternative are not unhappy with the engineering. They are unhappy with one of three specific things.

This post is about those three things, what to move to for each, and the cases where the honest answer is to stay where you are.

The three reasons people actually leave

The bill moves on its own. Supabase Pro is a $25 base plus usage meters: monthly active users (100k included), egress (250 GB), disk, and compute. None of those are unreasonable numbers. The problem is structural, not the rate card. You cannot answer "what will this cost next month" without predicting your own traffic, and the meter you blow through is rarely the one you were watching.

The free tier pauses. A free Supabase project pauses after about seven days with no activity. That is a defensible policy for idle infrastructure. What surprises people is the blast radius: a paused project takes its Auth API down with it, so every login fails until someone manually restores the project. A side project you show someone once a month is exactly the shape that breaks.

It is Postgres, and only Postgres. This is by design and it is the right call for Supabase. It stops being the right call for you the moment you need a cache, a search index, a vector store, or a time-series database, because each one becomes a separate vendor with a separate bill, a separate dashboard, and a separate on-call story.

Which of the three is biting you determines where you should go, so take them one at a time.

If the problem is the meter

You want flat pricing, which is a narrower market than it sounds like, because most managed Postgres is metered on something.

Neon is the strongest pure-Postgres option and its branching is genuinely good, but it bills on compute hours and storage, so you are trading one meter for a different one. That is a real improvement if your usage is spiky and idle-heavy. It is not an improvement if what you wanted was a number that does not move.

Layerbase Cloud is what I build, so read this with that in mind. It is flat: Free is $0 for 2 databases and 5 GB with no card, Solo is $5/month, and Pro is $15/month for up to 10 databases with 30-day backup retention. There is no meter on queries, connections, or egress. If you outgrow the included pool, capacity grows in $10/month blocks rather than by surprise. Pro has a 7-day trial.

On idling, be skeptical of anyone claiming their free tier never sleeps, including me. A free Layerbase database hibernates after an hour idle and wakes on connect in about one to five seconds, with no action from you. After 14 idle days it archives, and bringing it back is an explicit click. So the sleeping is real.

The difference is what sleeps with it. An archived database is a database: nothing else in your stack goes down because it dozed off, and there is no Auth API to fail closed. Paid plans never auto-archive at all, so $5/month makes the behavior go away rather than merely raising the ceiling.

If the problem is Postgres-only

Layerbase runs 18 engines in the cloud on one account and one bill: Postgres, MySQL, MariaDB, Redis, Valkey, ClickHouse, Qdrant, Weaviate, Meilisearch, QuestDB, InfluxDB, CouchDB, TypeDB, TigerBeetle, SQLite, libSQL, DuckDB, and FerretDB for MongoDB wire compatibility. Database branching works on 9 of them, not just Postgres, which is unusual enough to be worth checking against whatever else you are evaluating.

The honest framing is that this replaces the database half of Supabase and consolidates the vendors you were going to add anyway. It does not replace the rest of the bundle, which brings us to the part most posts like this skip.

What you actually lose

Layerbase gives you a management layer for auth on a database you own, not a hosted login service. We provision the database, scaffold the auth schema when you ask, and give you a console to see and manage user rows. The sign-in itself happens in your app, through Better Auth or whatever library you pick.

That is a real difference from Supabase Auth and you should price it in. Supabase Auth cannot run without a Supabase Postgres project, because the auth schema lives inside one, so "keep Supabase for auth only" means keeping a Supabase project alive regardless. If auth is the reason you are staying, stay.

You also lose storage, realtime subscriptions, and edge functions. There are good standalone answers for each, but "good standalone answer" means another vendor, and if you left Supabase to reduce vendor count you have gone in a circle. Be honest with yourself about which problem you are solving.

The comparison

When to stay on Supabase

Genuinely, and not as a rhetorical move:

• You use Supabase Auth and it works. The migration cost is real and the replacement is a library you now own. If nothing is broken, this is not worth your weekend.
• You want one vendor for the whole backend. That is the product. Nothing here beats it on that axis.
• Your usage is stable and small. If the meter has never surprised you, the meter is not your problem, and $25 flat-in-practice is a fine deal.

The case for moving is strongest when your bill has already surprised you at least once, or when you are about to add a second database type and are staring down a second vendor.

Moving

If you decide to go, the database half is the easy part: it is a Postgres dump and restore, and the Supabase migration guide walks the whole path including what to do about the auth schema. Plan the auth cutover separately and first, because that is the part that has a bad day if you rush it.

Start with the free tier. No card, two databases, and if it is not better than what you have, you have lost an afternoon.