Why every pick shows its exit cost

Most stack advice tells you what a tool can do. Almost none tells you what happens the day you want out. That is not an accident: choosing is when a vendor has your attention, and leaving is when it does not.

So every data and auth pick on projectnext.app renders an exit cost line. Not a badge, a scored line that says how your data comes out, whether your application code has to change, and exactly what you give up on the way out. Thirteen products are scored right now, and the two Layerbase ones are in that list on the same terms as everyone else.

What the score actually measures

The score has three parts, and they are deliberately narrow.

Data. How your rows come out. standard-dump means a normal dump that restores onto any comparable engine. export-tool means the data only comes out through the vendor's own exporter, in a shape you have to reshape yourself. proprietary means there is no supported export path at all, and getting your data out means reading it back through the product API and rebuilding it.

Code. How much of your application has to change. none means your code is untouched. driver-swap means you change the client library and re-test, but your schema and your queries come with you. rewrite means every part of your app that touches this has to be written again against a different data layer. That is a port, not a migration, and it is the difference between a weekend and a quarter.

What you forfeit. A plain list of the things that stop existing when you go. Branching. Autoscaling. A hosted login UI. Signed browser uploads. Not a penalty, just the accounting of what you were actually buying.

The code column is the one that decides whether you are a customer or a hostage. A standard dump is nice, but if your data access has to be rewritten before that dump is useful anywhere, portable data is a technicality. That is why a pick whose code cost is anything other than none can never render low-exit-cost copy on this site. The rule is enforced by a test, not by editorial discipline.

Why a tool built by a database company has to show its work

projectnext.app is built by the people who build Layerbase. Layerbase Cloud is one of the products the picker is allowed to recommend. If we do not say that plainly, on the page, the whole thing is an ad with a quiz attached.

Saying it plainly is not enough either, so the site is built so that the conflict of interest cannot quietly decide an answer. Four rules do the work.

Claims come out of an evidence table. Every capability behind a pick is a row in a matrix of seven providers, and each row carries the doc, changelog entry, or repo path it came from. Nothing in the copy layer may assert that a provider can do something. The sentences are rendered from the data.

Only shipped features count. A capability has to be both live and sourced before the recommender can read it. Our roadmap is not an argument. Layerbase realtime and object storage are on the roadmap and not shipped, so they count for exactly nothing in a recommendation, and a card may only mention them as a note that tells you to plan as if they do not exist. Row-level security, edge functions, and a customer-facing scheduler are not on the Layerbase feature list at all. If you ask for those, the card sends you somewhere else.

Conflicts get named, not resolved in our favor. When two of your answers genuinely pull apart, the card prints the trade-off instead of quietly picking a side. Ask for realtime and say you are lock-in averse, and there is no option that gives you both cheaply. You get told that, along with what each side of the trade actually costs.

Some answers get nothing from us. A content site and a CLI come back with no Layerbase product on the card. Those cases are asserted by tests, so if a future change starts inserting our products into them, the build fails.

Layerbase Cloud's own line reads: standard dump, no code change, and you forfeit branching workflows, TTL databases, and the auth console. Note the parenthetical on that last one. The auth console goes away, your auth does not. Layerbase never issues a session. What the managed auth feature does is scaffold auth that you own, running in your own database, which means nothing signs out when you leave. The Layerbase CLI is scored too, and the only thing it costs you to stop using it is the managed local engine lifecycle, because the engines it runs are the ordinary ones.

Two Postgres picks, the same data cost, opposite code costs

Supabase and Neon are both Postgres. Both score standard-dump on data. If data portability were the whole story, they would be interchangeable on the way out. They are not.

Neon scores none on code. The connection string changes, the driver does not, and your schema and queries move unchanged. You forfeit branching and autoscaling: conveniences, not code you own.

Supabase scores rewrite. Not because the Postgres is unusual, it is a dedicated Postgres instance and the dump is a real dump. It scores rewrite because the parts of Supabase worth using are the parts that are not Postgres. Auth issues and manages your sessions, so leaving means migrating users. RLS policies are the documented authorization model and they read Supabase Auth JWT claims, so the policies do not simply travel with the dump. Storage, realtime, and edge functions have no equivalent waiting on the other side.

That is not a criticism of Supabase. The integration is the product, and the integration is good. It is a statement of price. Convex sits further along the same axis: data comes out through an export tool, the code cost is a rewrite, and what you forfeit is close to everything, because data access is the platform. For a reactive app that can be the right trade. It should just be a trade you made on purpose.

"You can leave" is the strongest thing we can say

We would rather you pick Layerbase because the exit is cheap than because the exit is expensive. Those are the only two ways a vendor keeps customers, and the second one is a slow-burning liability. Every team that stays because leaving is too painful is a team looking for the first excuse to rip you out, and telling everyone why.

Printing the exit cost costs us something real. It moves some picks away from us, and it puts a forfeit list on our own card that no marketing page would volunteer. We think that is the trade. A recommendation you can check is worth more than one you have to trust, and the fastest way to make a recommendation checkable is to publish the part a vendor would normally leave out.

Answer the questions, then read the exit line on every card. If one of them looks wrong, it is rendered from data you can go and read.