What is Supabase, and what does it replace?

By Christophe Paka · Facts checked on 23 October 2026

A developer on r/webdev asked: "What's the point of supabase/firebase?" Why not an auth vendor for sign in, a managed database, and your own server? Another reader built a business app with an AI tool and wrote: "I personally don't know the back end stuff."

Both are asking what is Supabase for. Get the answer wrong and you may run six vendors, six bills and six sets of keys. And the rule for who may see a row ends up in three places, kept in sync by hand.

The figure puts the two shapes side by side: a backend from parts on the left, and on the right one Postgres database (an open source store of linked tables) with every service around it. Built on Lovable Cloud? That is Supabase too, run by Lovable for you.

Left: six vendor boxes, each with its own key, bill and status page. Right: one Postgres database with Auth, Storage, Cron, Realtime, Edge Functions and Vectors around it, reached by one URL and one publishable key.
Figure 1.1: Six vendors, or one Postgres. On the left every piece has its own key and bill; on the right they share one database, one key and one set of access rules.

How to read this figure

  1. Start with the six boxes on the left. Each box is a separate company: a database host, an auth vendor, a file store, a live updates service, a timed jobs server and a vector database (a store built for search by meaning). Each one carries its own key, its own bill and its own status page.

  2. Read the second line in each box. This is where the trouble hides. The database host and the auth vendor each keep a user table. The file store has its own access rules. So each vendor has its own idea of who the user is.

  3. Read the cost box under them. Six keys to rotate. Six invoices to check. Six status pages to open when something breaks. And the rule for who may see a row is written three times, once per vendor that guards data, each in its own format. Each part is fine. Together they are a second job.

  4. Cross to the green Postgres box. On the right, the same six jobs sit around one Postgres database with one user table. The small grey names are the open source programs behind each service. You can skip them at first.

  5. Finish at the bottom box. Your app reaches all of it through one URL and one publishable key, a public key that only names your project. Every service reads the same database, so the rule for who may see a row is written once, as a Row Level Security policy. That is a rule inside the database, such as "a user sees only their own orders". The map of every service around one Postgres shows each box up close.

Key takeaways

  • Count your vendors, keys and bills before you pick a shape for your backend.
  • Treat the publishable key as public, and put your trust in the rules inside the database.
  • Write who may see a row once, as a Row Level Security policy on each table.

Try this: is Supabase for you right now?

Run the book's short checklist before you commit. Answer each line for your own app, with a yes or a no.

  1. Check your data. Does it have relations, such as users who own things, teams, and orders that point at customers?
  2. Name the person who will write or review the access rules in SQL. Your AI tool can write them, but someone must read them.
  3. If your data must stay in one country, pick a region (the place where the servers sit) in that country when you create the project. Running Supabase on your own server saves the fee, but updates, backups and monitoring become your job. New to servers? Stay on the platform.
  4. Price the exit. A dump file moves your tables and rows to any other Postgres host. Sign in, files and server code each need their own step.

Expected result: Yes on all four, and Supabase fits. If you store loose documents with no links, a document store such as Firebase fits better.

Questions readers ask

What's the point of Supabase over an auth vendor plus a managed database?

With parts, each vendor keeps its own idea of who the user is, and you sync the access rules by hand. Supabase puts sign in, files, server code, live updates and search around one Postgres database with one user table. One set of rules covers all of it. You can still plug in another sign in service or your own server.

Does Supabase cost anything to start?

No. A first project costs nothing: you get two active projects, a 500 MB database and 50,000 monthly active users. After a week without activity, a Free project pauses until you restore it. Paid plans start with Pro, at $25 a month per organization. Each project adds server time from $10 a month, and Pro includes a $10 credit. So three small apps on Pro cost $45 a month.

Do I need Supabase if I never write code?

You may have it already. Lovable, Bolt, Cursor, Replit and Claude Code reach for Supabase when an app needs a backend, and Lovable Cloud is Supabase run by Lovable. Do not assume the access rules are in place. The book gives five checks: five screens you read in a browser. On Lovable Cloud you cannot open them, so you send Lovable a question instead.

Is Supabase the same as Firebase?

No. Firebase's database is a document store, with no tables or rows, and it bills each read and write past a free daily amount. Supabase is a Postgres database whose tables can point at each other. Pick Firebase for loose documents and Google's tools. Pick Supabase for related data and SQL.

Sources: Supabase architecture (Supabase docs); Database overview (Supabase docs).

This figure is from Supabase Made Crystal Clear, chapter 1.

The chapter builds the idea step by step, with recipes you can follow, a Try it to check yourself, and every source.

Get the book

All diagrams