What is Supabase, and why is everyone using it?

What is Supabase? A hosted Postgres database that comes with sign-in, file storage, Realtime updates, server functions and an API generated from your tables, all run from one dashboard. That bundle is why so many apps start on it, Lovable’s built-in backend among them, and its defaults are where the first problems after launch begin.

What is Supabase, in simple terms?

Supabase is a hosted backend built on an ordinary Postgres database. One project gives you the database, user sign-in, file storage, Realtime updates, server-side Edge Functions and an API generated from your tables, so a small team can ship an app without running its own servers.

For most apps, Supabase works like this: the browser calls the Data API, which Supabase generates from your database schema with PostgREST, using your project URL and a publishable key that Supabase calls safe to expose in a web page (the older name for it is the anon key). Postgres grants then decide which roles can reach a table, and row level security policies decide which rows those roles can read or change. Supabase’s Data API guide calls that browser-to-database path a two-tier architecture; you can also put your own API server, or an Edge Function, in between. Whether that design holds for your data is the question behind whether Supabase is safe for your app.

Explained to a beginner, Supabase is everything an app keeps behind its screens: the accounts, the data, the uploaded files and the code that must never run in a browser. Supabase describes itself as “The Postgres Development Platform”, and the home page shows the dashboard’s Table Editor, SQL Editor and RLS Policies screens as the place you manage it.

What is Supabase used for: the six pieces

What Supabase does for an app splits into six pieces, and most uses of Supabase lean on several of them at once. The right-hand column is our reading of the work each piece still leaves with the owner; Supabase’s docs describe the pieces, not the jobs.

Auth is what lets row level security know who is asking: Supabase’s Auth guide says the SDKs send the user’s token with each data request, and that the token scopes database access row by row when used with RLS policies. Supabase’s Edge Functions guide says credentials go in project secrets, read through environment variables. Supabase’s vector columns guide describes pgvector as a Postgres extension that can be used to store embeddings, so an AI feature can keep its vectors next to its users. Realtime checks every change against each subscriber, so the work to do when Supabase Realtime is slow differs from tuning ordinary queries.

Why is Supabase so popular, and why use Supabase for a new app?

Supabase is popular because choosing it settles several backend decisions at once: real Postgres, authentication, storage and a ready API in one project, with a Free plan to start on. AI builders made it more common still, since several connect to it directly or run on it.

The first reason someone would use Supabase for a new app is the cost of starting. On 21 October 2026 the Free plan on Supabase’s pricing page listed 50,000 monthly active users and unlimited API requests. Paid tiers, overages and the point where a project outgrows the Free plan are a separate subject: what each Supabase plan includes.

The second reason is the database. Supabase’s home page calls every project “a full Postgres database”, and its architecture guide says Supabase does not abstract Postgres: you can use it with full privileges. The schema a builder writes there is plain SQL that any developer you hire later can read.

As for how popular Supabase is, the scale figures come from Supabase itself. Its Series F announcement of 4 June 2026 said nearly 10 million developers build on Supabase, more than double the number eight months earlier, and that database launches had grown 600% in a year. Put together, those reasons explain why it can look as if everyone using an AI app builder lands on Supabase.

The data model is the plainest answer to why Supabase is used in place of Firebase for apps whose records point at one another, such as users, accounts and orders. Supabase’s architecture guide says it chose Postgres rather than a NoSQL store on purpose, while Firebase’s Firestore and Realtime Database are NoSQL cloud databases, though Firebase now also lists a PostgreSQL service, SQL Connect. Pricing, rules, exit paths and the rest are in the Supabase vs Firebase comparison.

Do any big companies use Supabase?

Yes. Supabase’s customer stories page names Lovable, Chatbase, Brevo, eXp Realty, Udio, Resend, Mobbin and Firecrawl among its case studies, next to a two-person game studio. So Supabase runs under well-known products and very small teams alike. Which large companies use Supabase is something the page only partly answers, because it lists stories, not company sizes. A customer list tells you who uses Supabase; whether it fits your workload is a separate test, and the three checks near the end of this page are that test.

Why AI coding tools often choose Supabase

Lovable’s Cloud documentation says its built-in backend, on by default, utilizes Supabase’s open-source foundation, giving a database, real-time updates, user authentication and storage without a separate Supabase setup. Lovable also connects a Supabase project you own and uses it as the app’s backend: it designs the schema, runs migrations and deploys edge functions from the project chat. Bolt’s Supabase integration offers Supabase on paid plans as an alternative to its own Bolt Database, for a database, authentication or edge functions.

In our reading, coding tools that ship no backend of their own, Cursor and Claude Code among them, often reach for Supabase when the code they write needs one. Supabase’s own Series F announcement put more than 60% of new databases on its platform down to “some sort of AI tool”. The result is that the builder picked Supabase before the owner had an opinion, so the defaults in the next section were inherited rather than chosen. If you built on Lovable, the choice between Lovable Cloud or your own Supabase project decides whose account the database lives in.

If a builder picked Supabase for your app and real users or customer data are close, start with a free audit: a video call where we go over with you what the builder chose on your behalf and agree what to check before launch. In the sprint, our engineers implement and test Row-Level Security or equivalent server-side scoping across all tables, verify automated backups, set retention and perform a real restore test, configure connection pooling and test it under load, and move schema changes into ordered migrations committed to the repository. Hosting, paid tools and API usage are paid through your accounts, so a bigger Supabase plan stays on your own bill.

What are the disadvantages of Supabase? Four defaults that bite after launch

The disadvantages of Supabase are the jobs its defaults leave with you: row level security on every table the browser can reach, schema changes kept as migrations, the right connection pooler for server code, and backups you have restored at least once. None of them shows up in a demo.

In our view, the downsides of Supabase come down to ownership: the strongest reason not to use Supabase is these four jobs landing on a team with nobody to own them. If the reason is a different data model or hosting setup, the comparison to make is what you would rebuild on another platform. Each of the four Supabase cons below names what to look at in your own project, and none of these limitations needs a move off Supabase to fix.

1. Tables created in SQL need row level security switched on

Tables created through the Supabase dashboard have RLS enabled by default; a table created in the SQL Editor or through another tool, such as a migration script, needs it enabled explicitly. Supabase’s Data API security guide separates two controls: grants determine which Postgres roles can reach a table, and RLS policies determine which rows those roles can read or modify. A table with RLS disabled is not automatically reachable; it is reachable when the role also has the necessary privilege and the table sits in an exposed schema. The two failures look different: a missing grant returns error 42501, while a row a policy filters out raises nothing and is simply absent from the result.

The grant defaults are changing too. Supabase’s changelog says that from May 30, 2026 new projects began, in a gradual rollout, to stop exposing new tables in the public schema to the Data API until a grant opts them in, and that on October 30, 2026 the setting will be applied to all existing projects; existing tables keep their current grants. Supabase’s Security Advisor flags tables with RLS disabled in public schemas and tables with RLS enabled but no policies.

-- a table created in the SQL Editor or a migration
create table public.invoices (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users,
  amount_cents integer not null
);

alter table public.invoices enable row level security;
grant select on table public.invoices to authenticated;

create policy "Owners read their own invoices"
on public.invoices for select to authenticated
using ((select auth.uid()) = user_id);

Take an app where every table from the first build has RLS and an owner policy. Later, a new feature needs a new table, and it is created in an exposed schema without RLS. The API roles hold privileges on it, so it is reachable, and the Security Advisor lists it as RLS disabled: the rest of the app is locked and this one table is open. RLS working somewhere is not RLS everywhere, so check every table, the one added last week included.

We audited 21 third-party apps in June and July 2026, and 9 of the 21 had row-level security gaps. The 21 were a selected set rather than a random sample, so the 9 describes that group only.

The policy patterns that keep working as an app grows are in the RLS practices that hold after launch, and the gaps a policy cannot close are weighed in whether RLS alone is enough.

2. The schema lives in the dashboard, not the repository

Supabase’s migration guide warns that schema changes made directly on the remote database, in the SQL Editor or the Table Editor, bypass the migration history. When a schema was built that way, the repository cannot rebuild or review the database, and a Supabase staging environment cannot be created from the repository alone. One app we audited kept every table, constraint and row-level security policy in a schema that lived only in the dashboard. The way back is database migrations: for changes made on the remote database directly, the same guide says supabase db pull creates a new migration file capturing the current remote schema; you commit that file to git and follow the standard migration workflow from then on. The steps, from the first file to the production run, are in the database migration checklist.

3. Server code needs the right connection pooler

A browser app goes through the Data API and needs no Postgres connection string. A backend, an ORM, a worker or a serverless function that holds a connection string opens real Postgres connections, and Supabase’s connection guide matches the connection to where the code runs. A persistent backend on IPv6, or with the IPv4 add-on, uses a direct connection; a persistent backend on an IPv4-only network uses Supavisor’s shared pooler in session mode; serverless and edge functions, which open many short-lived connections, use the shared pooler in transaction mode. Transaction mode does not support prepared statements, so the connection library needs them turned off. The wrong choice can surface during busy periods as a Supabase connection pool that runs out.

4. Backups exist on paper until one is restored

Supabase’s backups documentation says Pro, Team and Enterprise projects are backed up daily, with the last 7, 14 and up to 30 days of daily backups available on those plans; for free projects it recommends regular exports with the Supabase CLI’s db dump command and off-site backups. Database backups do not include objects stored through the Storage API, because the database holds only their metadata. Deleting a project permanently removes its data, including any backups stored in S3. A backup list in the dashboard proves a file exists; only a restore into a separate project proves it works. The plan-by-plan detail is in what a Supabase backup actually covers.

Is Supabase just a database, or a backend? Postgres underneath

Supabase is more than a database and less than a full application server. Underneath sits a standard Postgres database you can reach with SQL and any Postgres tool; around it Supabase adds sign-in, storage, Realtime, functions and a generated API.

The database Supabase uses is Postgres, and the type of database Supabase runs is relational: tables, rows, foreign keys and SQL. Supabase vs plain Postgres comes down to what surrounds it: the same database, plus hosted sign-in, storage, Realtime, functions and a generated API, where a Postgres you run yourself leaves each of those to you. Because Supabase does not abstract the database, pg_dump can export it as a plain-text SQL script, which the PostgreSQL docs say can reconstruct the database even on other machines. Files in Storage travel separately, since the database holds only their metadata.

Supabase is open source. Supabase’s architecture guide lists each component with its license: Postgres under the PostgreSQL License, GoTrue (Auth) and PostgREST under MIT, Studio, Realtime, the Storage API and Supavisor under Apache 2.0, and Deno, which runs Edge Functions, under MIT. Supabase’s self-hosting guide covers running your own Supabase on your computer, server or cloud infrastructure, and names Docker as the fastest and recommended way. Self-hosting as an exit, and the other platforms, belong to the alternatives comparison in the section above.

Is Supabase good for a launch? Three checks before you rely on it

Supabase is a good choice for a launch once three checks pass: a second account cannot read the first account’s rows, the repository can rebuild the schema in a fresh project, and a backup has been restored somewhere safe and its data checked.

Whether Supabase is actually good for your app turns on these checks more than on the platform, and each one leaves evidence you can keep:

1. 01 Sign in as a second account and try to read the first account's rows, changing only an id in the request. Keep the response: an empty result means a policy filtered the rows out.
2. 02 Build a fresh project from the repository's migrations alone and compare its schema with production. Keep the diff.
3. 03 Restore a backup into a separate project and spot-check a few rows you know. Keep the date and what you checked.

Whether Supabase is good for big projects is a scale question, answered under whether Supabase can handle more users. The question of whether you should use Supabase at all gets easier once the three checks have run, and a failed check is a reason to fix a default, which you can do without leaving the platform. If Supabase is worth keeping for your launch, the next step is the rest of the launch list: the full production readiness list sorts every item by area, with how each one is verified.

Data isolation across every table is deliverable 1.4 in the sprint, and it is verified this way: run read and write tests as anonymous users, different roles, and separate tenants. Check 1 above is the smallest form of that test. The access-control items around it, from sign-in flows to admin roles, are in the authentication checklist.

Common questions about Supabase

Is Supabase 100% free?

No. Supabase’s Free plan costs nothing but has limits: on 21 October 2026 its pricing page listed 500 MB of database size, 1 GB of file storage, a pause after one week of inactivity and two active projects at most. Paid plans start with Pro.

Is Supabase owned by Google?

No. The company page of Supabase Inc says it has raised $1 billion in funding from investors it names, and the page never names Google as an owner or investor. Its latest round, a Series F announced on 4 June 2026, was led by GIC.

Which version of PostgreSQL does Supabase use?

Postgres 17. A Supabase changelog entry of 18 May 2026 says Postgres 17 is what Supabase currently defaults to on its platform, and Supabase’s upgrade guide covers moving existing Postgres 15 projects to Postgres 17.

Is Supabase a NoSQL or SQL?

SQL. Supabase runs on Postgres, and its architecture guide says it uses Postgres rather than a NoSQL store by deliberate choice. Postgres also has json and jsonb columns for unstructured data, with jsonb recommended for almost all cases, so document-shaped data can sit inside the relational tables.

When should a founder get help with an app built on Supabase?

A founder should get help before real users arrive if a builder created the tables, or if nobody on the team can say which tables have RLS and whether a backup has ever been restored. AxonBuild offers a free audit, where we weigh up with you what your launch needs first.