What Is Supabase? A Plain-English Guide for App Builders

What is Supabase? Supabase is a hosted backend built on a Postgres database. On top of the database it gives you sign-in (Auth), file storage, edge functions, realtime updates and an auto-generated API, so a web or mobile app can read and write data without you writing a server first. It's open source, and it's the backend that Lovable and Bolt connect to when your AI-built app needs real data.

By Gary, Greenlight My App · Updated Oct 22, 2026 · How we checked this: every fact below links to Supabase's or Firebase's own docs, read on Oct 22, 2026. The RLS test ran on our own demo setup with fake rows only (details in the RLS test section below). Drafted with AI tools and reviewed by a person before publishing.

What is Supabase?

Supabase describes itself as a "Postgres development platform" that "gives you a dedicated Postgres database to build your web, mobile, and AI applications" (Supabase on GitHub (external)). In plain English, it's the back half of an app, already built and hosted for you.

Here is what you get with every project, per the Supabase docs (external):

People often call it an "open source Firebase alternative." That's a fair shorthand for what it competes with, but the big difference is under the hood: Supabase is a relational SQL database (Postgres), not a document store. More on that in the Firebase section below.

Our demo project's home screen on Oct 22, 2026 (Free plan, fake data only). No keys are shown on this screen.

What is Supabase used for?

Supabase is used to store and protect an app's data without building a backend from scratch. Typical jobs in an AI-built app:

• Storing app data. Every list, post, booking or note your app saves lives in a Postgres table.
• Logins. Supabase Auth handles sign-up, sign-in and sessions, and tells the database who the current user is.
• File uploads. Storage buckets hold images and documents, with their own access rules (storage access control (external)).
• Server-side jobs. Edge Functions (external) run code you don't want in the browser, such as calls that need a secret key.
• The backend for AI app builders. Lovable and Bolt both document a built-in Supabase connection (Lovable docs (external), Bolt docs (external)), and apps written with Cursor commonly use the same supabase-js client.

So if you've ever asked an AI builder to "add a database" or "add login," there's a good chance you're already a Supabase user.

How does Supabase work with Lovable, Bolt and Cursor apps?

The browser talks to Supabase directly. Most AI-built apps don't have their own server in the middle. The page you ship includes your Supabase project URL and a public key, and the supabase-js client sends requests straight to Supabase's Data API (/rest/v1/).

That design is fast and simple, but it means one thing matters more than anything else: the database rules do the protecting, not the key. Anyone can open your site, read the public key from the page, and send the same requests your app sends. What they get back depends on your Row Level Security policies and grants.

How a request flows: public key → Data API → RLS policy → table. The secret key lives on a separate, server-only path. Original diagram by Greenlight My App.

In our demo app, the public key sits in the JavaScript bundle any visitor can download, exactly as it does in a typical Lovable or Bolt app. Blurred here anyway.

Supabase's own docs put it this way: the publishable key "is taped to the front door, and it only opens the lobby. The secret key is the master key" (API keys (external)).

Which Supabase keys are public, and which must stay secret?

Supabase supports four key types today, two current and two legacy (API keys docs (external)):

Supabase says it is "deprecating the anon and service_role keys by the end of 2026" in favor of publishable and secret keys. Both systems work side by side until you turn the legacy keys off.

On our hosted demo project, the dashboard's API Keys page showed two tabs on Oct 22, 2026: "Publishable and secret API keys" and "Legacy anon, service_role API keys," with the anon key tagged public and service_role tagged secret. (We didn't screenshot that page because it shows key values.)

The two kinds of keys in our test setup: a public key for the browser and a server-only secret. Values blurred.

The rule of thumb: a public key in your frontend is fine if RLS protects your tables. A secret key in your frontend is never fine, because "policies never apply to a secret key" (Supabase docs). For more, see is my Supabase anon key safe? and what to do if your service role key is exposed.

What is Row Level Security (RLS) in Supabase?

Row Level Security is a Postgres feature that filters which rows each role can see or change. With RLS on, every query is checked against the table's policies. With no matching policy, the query simply returns nothing (Supabase RLS docs (external)). Supabase's docs tell you to "enable it on every table before you deploy."

What happened when we tested RLS?

We wanted to see the difference with real requests instead of describing it. On Oct 22, 2026, we ran this on our own demo setup:

• Setup: PostgreSQL 17.11 and PostgREST 16.5 (the open-source engine behind Supabase's Data API) running locally, with Supabase-style anon and authenticated roles and the old default grants. This was not a hosted Supabase project; the hosted demo project above was used only for the dashboard and Security Advisor screenshots.
• Data: one table, demo_notes, with 3 fake rows belonging to 2 fake users.
• Request: the same GET /demo_notes?select=* call a browser app makes, sent with the public (anon) key.

Step 1: RLS off. Anyone with the public key reads every row.

Step 2: RLS on with no policy. Same request, nothing comes back, and there's no error message to warn you.

Step 3: the policy lets a signed-in user read only their own rows. User two's note stays hidden.

The policy we used (from Supabase's own pattern):

alter table public.demo_notes enable row level security;

create policy "signed-in users read own notes"
  on public.demo_notes
  for select
  to authenticated
  using ((select auth.uid()) = user_id);

Two things stand out from this test. First, turning RLS on with no policy doesn't throw an error; your app just gets empty lists. Second, the fix is a policy, not a different key. For a deeper walkthrough, read what is Supabase RLS? and our Postgres row level security guide.

What changes on October 30, 2026?

From Oct 30, 2026, new tables you create in the public schema of an existing Supabase project need an explicit GRANT before the Data API can see them. Existing tables keep their current grants. Supabase announced the change in its changelog (external):

Supabase notes that "RLS behavior remains unchanged." Grants decide whether a role can reach a table at all; RLS decides which rows it sees. A missing grant shows up as error 42501, "permission denied for table."

We cover what to do in detail on our Supabase Oct 30 change page, and the error itself in Supabase permission denied for table.

Is Supabase free, and how does it compare to Firebase?

Yes, Supabase has a Free plan. Paid plans start with Pro. As listed on Supabase's pricing page (external):

Prices as of Oct 22, 2026. Check the official page before you rely on them.

Supabase vs Firebase, briefly. Both give you a hosted database, sign-in and storage. The main difference is the database model: Supabase is a relational Postgres (SQL) database, while Firebase's Cloud Firestore (external) is a NoSQL document database. Access control differs too: Supabase uses Postgres grants and RLS policies, while Firebase uses Firebase Security Rules (external). Neither is "more secure" by default; both depend on the rules you write. If your AI builder already set up Supabase, that's the one to learn.

Compared on Oct 22, 2026; based on Supabase's and Firebase's public sites.

Is Supabase secure? A 5-minute check before launch

Supabase gives you the tools to lock data down, but your project is only as safe as its settings. It's a configuration question, not a verdict on the platform. Before you launch, run through this:

What does the Security Advisor show?

Supabase's Advisors (external) check your project for common problems. On our hosted demo project with RLS off, the Security Advisor showed 1 error: "RLS Disabled in Public" on public.demo_notes.

Hosted demo project, RLS off: the Security Advisor flags the table.

On our local setup we ran the same open-source lint checks the Advisor is built on (Supabase's splinter lints). With RLS off they returned the error "RLS Disabled in Public"; with RLS on and no policy, the info note "RLS Enabled No Policy"; with the policy in place, nothing.

The same checks across all three steps of our test.

What did a Greenlight My App scan show?

We pointed the Greenlight My App free scan at our demo app in both states. The scan reads your public page and scripts, finds a Supabase project URL and public key if they're there, and counts how many rows each table returns to that public key. It doesn't read the rows.

• RLS off: FAIL, "A Supabase table returned rows to your public key."
• RLS on: PASS, "None of the 1 tables we checked returned rows to the public key."
• Both runs: PASS for "No secret keys found in your public code," plus an info note about the Oct 30 change.

Scan of our demo app with RLS off.

Same demo app after turning RLS on.

A caveat, in the open: the scan ran against our local demo stack, which stood in for a hosted supabase.co project. The scanner code was unchanged. The scan doesn't log into Supabase, read your policies, test logins or app logic, and "nothing found" isn't a guarantee that nothing is exposed.

FAQ

What is Supabase used for? Storing an app's data in Postgres, handling sign-in, storing files, and running server-side functions. AI app builders such as Lovable and Bolt use it as the backend when your app needs a database or logins.

Is Supabase free? There's a Free plan at $0/month, and paid plans start with Pro from $25/month (compute for extra projects is billed separately) as of Oct 22, 2026. Check Supabase's pricing page (external) for current limits.

Is the Supabase anon key safe to put in my app? Yes, it's public by design, the same as the newer publishable key. It's only safe if Row Level Security protects your tables, because anyone can copy it from your page. See is my Supabase anon key safe?

What is RLS in Supabase? Row Level Security is a Postgres feature that filters which rows each user can read or change. In our demo, the public key read all 3 fake rows with RLS off and none with RLS on. See what is Supabase RLS?

Is Supabase better than Firebase? It depends on what you're building. Supabase is a SQL (Postgres) database with RLS policies; Firebase's Firestore is a NoSQL document database with Security Rules. If your AI builder already set up Supabase, stick with it and learn its security settings.

Is Supabase secure? Supabase provides RLS, grants, separate public and secret keys and a Security Advisor. Whether your app is secure depends on how those are set: RLS on every table, real policies, and no secret key in the browser.

Built on Supabase? Scan it before launch.

Built your app on Supabase with Lovable, Bolt or Cursor? Scan your app before launch with Greenlight My App's free scan. It checks for exposed keys and tables your public key can read. It's automated, read-only and educational, not a security audit, and "nothing found" isn't a guarantee that nothing is exposed. Run a free scan (external).