Blog
4 min read

What Is Supabase? A Beginner's Guide to the Backend Behind Many AI-Built Apps

Supabase gives your app a Postgres database, logins, file storage and serverless functions from one dashboard. What each part does, how the publishable and secret keys work, why row-level security matters, free-plan limits, and when to use something else.

If you built an app with Lovable, Bolt or another AI builder, there's a good chance it uses Supabase for its data and logins. Here's what Supabase actually is, how the pieces fit, and the one setting you must understand before real users arrive.

The short version

Supabase is a hosted backend. Instead of setting up your own database, login system and file storage, you create a Supabase project and get all of them at once, with a dashboard and an API your app can call directly.

At its heart is a real PostgreSQL database — the same open-source database many large companies run. (What's a database? See here.)

The main parts

Part What it does
Database A Postgres database with a spreadsheet-like table editor
Auth Sign-up, login, password reset, magic links, "Sign in with Google"
Storage File uploads — profile pictures, documents
Edge Functions Small pieces of server code for things that need secrets
Realtime Push database changes to browsers as they happen
Auto-generated API Read and write your tables from frontend code

How an app talks to Supabase

Your frontend uses the Supabase client library with your project URL and a key:

import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY
);

const { data } = await supabase.from("notes").select("*");

That last line reads from your notes table straight from the browser. No backend of your own is involved — which is what makes Supabase so quick to build with, and also why the next section matters so much.

The keys: which are safe to expose?

Supabase is moving from its original keys to new ones (the old ones are being deprecated by the end of 2026):

  • Publishable key (sb_publishable_...), replacing the old anon key. Safe to put in your frontend. It identifies your project but grants only what your security rules allow.
  • Secret key (sb_secret_...), replacing the old service_role key. Bypasses all security rules. Server-only, never in the browser. Supabase rejects secret keys sent from a browser.

If you ever see service_role or sb_secret_ in frontend code, treat it as leaked and rotate it. See I leaked an API key. What now?

Row-level security: the setting that matters most

Since the browser talks to the database directly with a public key, something has to stop user A reading user B's data. That's row-level security (RLS) — rules in the database saying which rows each logged-in user can see and change.

A table with RLS turned off, or with a policy like "anyone can read everything", is readable by anyone who opens your site's developer tools. This is the most common serious security flaw in AI-built apps. Before launch, read Supabase row-level security explained and check every table.

The free plan, and its catch

Supabase's free plan is generous for learning: a small database, file storage and tens of thousands of monthly active users. The catch for real apps: free projects pause after a week of inactivity, and stay unavailable until you unpause them in the dashboard. Fine for experiments; not for anything people rely on. Paid plans don't pause.

When Supabase is a good fit

  • You want logins, a database and storage working today, with little backend code.
  • Your app is mostly reading and writing data with clear per-user ownership.
  • You're comfortable writing RLS policies (or carefully reviewing the ones AI writes).

When to consider something else

  • You need long-running work — background jobs, scheduled tasks, processes that run for minutes. You'll want a server of your own beside the database. See your app needs background jobs.
  • You want all your business logic on a server you control, with the database never exposed to the browser.
  • You'd like everything — app, database, jobs — in one place rather than split across services.

Since Supabase is Postgres, moving away later is realistic: you can export your data with standard Postgres tools. (Supabase vs Firebase compares it with its main rival.)

The summary

  • Supabase = hosted Postgres + auth + storage + functions, with an API your frontend calls directly.
  • Publishable keys are public; secret keys (and old service_role keys) are server-only.
  • Row-level security is what keeps users' data private — check it on every table.
  • Free projects pause after a week idle.

EasySpawn takes the other approach: a server of your own with PostgreSQL running beside your app, so the database is never exposed to browsers and background jobs have somewhere to run. See how it works for AI-built apps or join the waitlist.

Related: Which Database Should an AI-Built App Use? · How to Add Login to an AI-Built App · Postgres vs MySQL · Authentication vs Authorization

Keep reading