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

Short version: the right alternative depends on which of three things is bothering you. If it is the metered bill, you want flat pricing, and Layerbase Cloud or self-hosting are the two shapes that give it to you. If it is the free-tier pause, you want a database that hibernates and wakes on connect rather than one that has to be manually restored. If it is Postgres-only, you want a platform that runs more than Postgres, and Neon is not that, whatever else it does well. If you are on Supabase Auth and it works, the honest answer is to stay.

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 15 minutes idle and wakes on connect in about one to five seconds, with no action from you. MariaDB, the one free engine that is slow to wake, sleeps after 30 idle minutes instead and takes about 20 seconds to come back. 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 16 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

Supabase figures verified 2026-08-25 from supabase.com/pricing: the $25 base on their Pro plan, the 500 MB and two-project free plan, and the one-week inactivity pause.

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.

FAQ

What is the best Supabase alternative?

There is no single one, because Supabase is a bundle and the alternatives are pieces. For flat-priced Postgres plus other engines, Layerbase Cloud. For metered Postgres with strong branching, Neon. For the whole bundle without a vendor, self-hosting the Supabase Docker stack. Pick against the specific thing that pushed you to look.

Why does my Supabase free project keep pausing?

A free project pauses after about seven days with no activity. The part that surprises people is not the pause itself but what pauses with it: the Auth API and PostgREST go down too, so every login fails until someone restores the project by hand. That is why a demo you show once a month is broken every time you open it.

Can I keep Supabase Auth and move only the database?

Not really. Supabase Auth cannot run without a Supabase Postgres project, because the auth schema lives inside one, so "auth only" still means keeping a Supabase project alive and paying for it. If auth is the reason you are staying, stay.

How does Layerbase Cloud pricing compare to Supabase Pro?

Supabase Pro is a $25 base plus meters on monthly active users, egress, disk, and compute. Layerbase 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. There is no meter on queries, connections, or egress, and extra capacity comes in $10/month blocks you choose rather than a curve you predict.

What do I actually lose by leaving Supabase?

Hosted auth, object storage, realtime subscriptions, and edge functions. We provision the database, scaffold the auth schema when you ask, and give you a console over the user rows, but the sign-in itself happens in your app through Better Auth or whatever library you pick. There are good standalone answers for storage and realtime, and every one of them is another vendor.

How many database engines does Layerbase Cloud run?

18, 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. Branching works on 16 of them rather than only Postgres.

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.