Why Everyone Uses Supabase, and What the Default Costs Later

Supabase is the default backend for AI-built apps because it removes four decisions at once: a real Postgres database nobody has to provision, authentication in one call, an API generated over every table the moment it exists, and a free tier that carries a launch. Five of the 26 apps in the AxonBuild audit corpus run on it.

Every one of those four is also a decision made for you, and three come due after launch. That is the whole post: why the default is good, and the bill it hands you later.

Why is Supabase so popular? It removes four decisions at once

Supabase is popular because picking it settles four separate backend arguments in one afternoon: ordinary Postgres instead of a proprietary document store, authentication included, an API over every table without a route written, and a free tier holding 500 MB of database and 50,000 monthly active users.

Those numbers come from Supabase’s pricing page, and the Postgres is real Postgres, so the schema you write is the schema any developer you later hire already knows.

Developers use Supabase because the alternatives land worse. Firebase matches the speed and takes Postgres away, so your data model bends to documents and your queries bend with it. Neon gives you Postgres with no auth, storage or generated API, so you are back to writing three services. Postgres you run yourself gives you everything and a pager. Supabase is the one spot where you get relational data, stop making infrastructure decisions, and have a working first version by evening. That is true, and this post does not argue with it.

What Supabase is actually used for

Supabase is a hosted Postgres database with four things bolted on: authentication, file storage, realtime subscriptions and auto-generated APIs over your tables. Teams use it as the whole backend of a web or mobile app, so accounts, application data, uploaded files and the API layer all come from one project.

Underneath, the browser talks to the database, with no server of yours in between unless you build one. That property is what makes Supabase fast to build on, and it is where every cost below comes from.

Why AI coding tools default to Supabase

AI builders default to Supabase because they ship native integrations for it, so the backend is chosen before the founder has an opinion. Lovable’s integration “connects a Supabase project you own to your Lovable project and uses it as your app’s backend,” designing the tables from a plain-language description. Bolt.new offers the same as a first-run choice on Vite projects. Supabase is a Vercel Native marketplace integration with a “Build in v0” button pointing at it.

For most of these founders, the builder picked Supabase before they had an opinion to pick with.

Not every tool works this way. Base44 ships its own managed data layer and has no official Supabase integration at all. Where a tool has no backend of its own, Cursor and Claude Code among them, the model reaches for Supabase because that is what most of the code it learned from does.

Either path ends the same way: a Postgres database, a public API key in the browser, and a security model nobody was in the room to explain.

Is Supabase 100% free? What the free tier actually carries

Supabase’s free tier is real and enough to launch on: 500 MB of database, 50,000 monthly active users, 5 GB of egress, two active projects. What it does not carry is a backup. Free projects get no automatic backups of any kind, so the only copy of your data is one you took yourself.

Paid plans close that gap less cleanly than founders assume. Pro’s rolling seven-day window only ever holds seven days, Storage files are not in the database backup at all, and deleting the project deletes the backups with it. What a Supabase backup actually covers, plan by plan takes that apart properly.

What are the disadvantages of Supabase? Three that bite after launch

The disadvantages of Supabase are the flip side of its four conveniences: Postgres you never provision, auth in one call, an API over every table, and a free tier that carries a launch. The limitations of Supabase that founders hit after launch all come out of those four, and each cost arrives only once real users do.

1. Row-level security is off unless you turned it on

Row-level security in Supabase is on by default for tables created one specific way, and AI builders do not use that way. Supabase’s documentation states RLS “is enabled by default on tables created with the Table Editor in the dashboard,” while a table created in raw SQL needs it switched on by hand. Builders create nearly every table through SQL and migrations. So the tables you create by clicking start protected, and the tables your builder creates start open.

-- created by a migration, which is how AI builders create nearly every table
create table public.notifications (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users,
  body text
);

-- until this line runs, anyone holding the public key can read the whole table:
alter table public.notifications enable row level security;

That gap is measurable. Across the 21 third-party apps AxonBuild audited in June and July 2026, 9 carried a genuine row-level security hole and 7 let a signed-in user reach rows belonging to a different customer, every finding verified against the code, not pattern-matched. Authorization came out at 42.1 out of 100 across the 14 apps where the pillar applied, fifth-worst of the twelve areas I score, and the full corpus numbers sit behind that one.

Two of the Supabase-backed apps reached the same exposure from opposite directions. In a food-delivery app scoring 37 out of 100, a notifications table added after the rest of the schema had never had RLS switched on, while a trigger copied each order’s customer name, phone, address and GPS coordinates into it. In a public Q&A platform scoring 48 out of 100, with no health or payment data anywhere near it, RLS was on for every single table, and a second policy on the profiles table read using (true), which is the version that unsettles me more. One of those two shows a green toggle and the other does not, and both hand over the table. That distinction is what Supabase itself is safe, and which half of that question is yours turns on. Switching RLS on settles less than founders expect: whether RLS by itself is enough, and the policy practices that keep row-level security holding once it is on, are each their own subject.

2. Your schema can live in a dashboard instead of your repo

The finding that bothers me most in this group had a clean schema behind it. A golf analytics app, 59 out of 100 and the strongest of the five, kept every table, constraint and RLS policy only in the hosted dashboard, with no committed migrations anywhere in the repo. Nothing in that schema was wrong the day I read it, and none of it could be checked either: the authorization posture was unreadable from the code, a bad dashboard change would leave no diff and no rollback, and setting up a staging environment on Supabase to test against was not possible from what the repo held. Same shape as deleting production data with no way back, waiting on someone clicking the wrong thing on a Tuesday.

Supabase does not encourage this. The dashboard is a good dashboard, just faster than writing a migration, and a builder that edits the schema through the API has no reason to leave a file behind.

3. Connection limits arrive earlier than expected

The third one is dull and reaches most apps first: a small compute tier has a modest ceiling on direct connections, and a serverless app opening a client per request finds it quickly. The fix is the pooler, a settings change rather than a rewrite. Why a Supabase app gets slow, and where the four causes actually live covers the query side in full, and the same unbounded queries turn up later as a Supabase egress limit nobody priced.

So is Supabase really worth it? Yes, and here is the bill

Supabase is worth it. The default is good, the Supabase alternatives are worse for a solo founder, and picking it was not a mistake. It is also not a finished decision. Three checks turn it from a default you inherited into a choice you made:

1. 01 Sign in as a second account and try to read the first account’s data, changing nothing but an id. If it comes back, row-level security is not holding, whatever the dashboard shows.
2. 02 List every table created after your original launch and check RLS on each one by name. Those are the tables the first setup never covered.
3. 03 Try rebuilding your schema into a fresh project from your repo alone. If you cannot, your authorization rules exist in one place and have never been backed up.

Half an hour of that, and whether someone can steal data from your Supabase app stops being an answer you inherited from a builder’s default. Authorization is one of the twelve areas that decide whether an AI-built app is actually ready to launch, and it is the one Supabase’s convenience puts most directly in your hands.

I still do not have a good answer for why the strongest of those five apps was the one with no migrations in it.

Common questions about Supabase

Is Supabase really worth it?

Yes, for most AI-built apps. Real Postgres, auth, storage and a generated API with nothing to provision beats Firebase’s document model or a Postgres host with no auth attached. The cost is that the security model is yours to configure, and 9 of the 21 third-party apps AxonBuild audited had not configured it correctly.

Is Supabase owned by Google?

No. Supabase is an independent company, founded in 2020 by Paul Copplestone and Ant Wilson and funded through Y Combinator’s Summer 2020 batch. No Google entity owns or controls it. The confusion is understandable, because Firebase is the product Supabase gets compared against and Google does own that one. Supabase’s money comes from venture investors: its own Series F announcement puts the June 2026 round at $500 million led by GIC, four months after a $100 million Series E co-led by Accel and Peak XV, with Y Combinator still on the cap table from the seed. Checked 29 July 2026. None of that changes what your app has to do, which is switch on row-level security and write the policies.

Which companies use Supabase in production?

Plenty of real ones, and you do not have to take that on faith because the list is public. Supabase publishes customer stories from more than forty companies including Resend, Mobbin, Udio, Chatbase, Firecrawl, Deriv and Brevo, verified on 29 July 2026. Lovable, the builder that wires Supabase into its users’ projects, is a Supabase customer itself. So whether big companies run Supabase in production is settled, and it is also not the question that decides anything for you. Whether the row-level security policies on your own project hold is.

Is Supabase 100% free?

Not entirely, though the free tier is real: 500 MB of database, 50,000 monthly active users, 5 GB of egress and two active projects, per Supabase’s pricing page. It includes no automatic backups, and free projects pause after a week of inactivity, so a launch that goes quiet comes back to a paused database.

Why do developers stop using Supabase?

Cost at scale and connection limits both come up, and what each Supabase alternative actually hands back to you is the honest version of that shopping trip. In the apps I audit the pressure point is the first of the three above: the browser-to-database model puts every authorization decision into RLS policies somebody maintains by hand, forever. Starting on Supabase is still the right call. Knowing which decisions it made for you, before your app has customers in it, is the part nobody hands you.