Reeve Security basics
What is Supabase? The database your builder picked for you
What is Supabase: the database, login and file storage behind your app. Supabase runs the servers; the rules about who reads your rows are yours.
In short
- What is Supabase? It is where your app keeps everything it has to remember: your users and their passwords, the rows behind every list, and the files people upload.
- Your builder almost certainly chose it for you while it was setting the project up, which is why nobody walked you through it.
- Supabase runs the machines. The rules about who can read which rows are yours, and on a table created with SQL they start switched off.
Your app works. Somewhere in its settings, or in an email about a bill, or in the middle of a message from Lovable, is the word Supabase. Sooner or later you have to find out what it is, and the reason is rarely curiosity: a scan mentioned your Supabase project, or a developer asked which plan you are on, or your app stopped saving things and the answer is somewhere in there.
So: what is Supabase. Every other explanation answers that as a choice between tools, which is the question a developer asks before starting a project. You never made that choice. Your builder made it in the seconds it took to set the project up, and that is why nobody walked you through the thing now holding all of your users' data.
This is the version for somebody who already has one.
What is Supabase, in one sentence?
It is where your app keeps everything it has to remember.
Your users and their passwords. The rows behind every list your app shows. The images and documents people upload. When somebody signs up at two in the morning, the record of that lands in your Supabase project and is still there after the browser tab closes.
Underneath it is Postgres, a database that has been in production use since the nineties and is not going to surprise you. What Supabase adds is everything around it: a login system, a place for files, and a way for your app to ask for data straight from the browser without you writing a server.
That last one is where your own decisions start.
The four pieces you actually have
Four, and your app is probably using at least two.
- The database. Tables of rows: your users, your orders, your posts. The part people mean when they say "Supabase".
- Auth. Signing up, signing in, resetting a password. If your app has accounts, they live here.
- Storage. Uploaded files, in named buckets. Profile pictures, attachments, exports.
- Edge functions. Small pieces of code that run on Supabase's servers instead of in your visitor's browser. Your app may have none of these, and there is one good reason to care anyway, further down.
Your dashboard lists more than those four. Leave the rest alone until something you are building needs it.
Which parts does Supabase look after, and which parts are mine?
Supabase looks after the machines. You look after the rules.
The split sits further up than most people assume. Think of the project as premises you rent. The landlord maintains the building, the power and the front door. What you keep inside, and who you let in, was never theirs to decide.
| What Supabase runs | What is yours |
|---|---|
| The servers, the Postgres version and the updates | Which rows each visitor is allowed to read |
| Daily backups of your database on the paid plans, kept for a week | Whether a copy exists anywhere your own project cannot reach |
| Encrypting your data on their disks and on the way to your app | Who holds your keys, and which key is in your app |
| Keeping the login system working | Which files in a bucket anyone can list |
Nothing in the left column fails quietly: if Supabase has an outage you will hear about it from your users within minutes. The right column is where things go wrong with no sound at all, because nothing breaks. Your app carries on working exactly as it did yesterday.
Is my Supabase data private by default?
It depends on how each table was made, and the way a builder makes them is the way that leaves them open.
Supabase's own documentation is direct about it. "The Table Editor enables row level security for you when you create a table in the Dashboard. When you create a table with SQL, enable it yourself." Row level security is the per-table setting that decides which rows a visitor may read. Your builder writes SQL, so a table your builder made arrives with that setting off.
The next sentence of the same page says what that leaves behind: "A table in the
public schema is reachable through the Data API. Until you enable row level
security and write a policy, anyone holding your project's publishable key can
read and write every row in it." That key is in your app, where it belongs, and
anybody can read it out of the page.
So the lock on each table is the thing to go and look at, and it is per table rather than per project. How to turn it on, and what a policy is is the walkthrough. We also counted how often it is missing: 2,096 of the 3,680 apps whose Supabase database answered us had at least one table handing its rows to a stranger.
If you would rather see it from outside than read down a list of tables, our free scan asks your project the question a stranger's browser would ask and shows you what came back. It takes about 20 seconds and needs no account: scan your app free.
Where your keys are, and which one is public
Your API settings page holds values of two kinds, and only one kind belongs in your app.
A key beginning sb_publishable_, called anon in an older project, is meant
to be public and does nothing on its own except say which project a request is
for. A key beginning sb_secret_, called service_role in an older project,
goes straight past every rule you set. Supabase puts it plainly: a secret key
"bypasses RLS, so keep it server-side". That is also the one good reason to care
about edge functions, because a function is where work that needs a secret key
can happen without the key going anywhere near a browser.
Where that page is and what each value on it does covers the locations, and which keys are safe in a frontend covers how to tell two near-identical keys apart.
Keeping it yours after you publish
What you find today describes today's app. The next table your builder adds arrives under the same default as the last one, and nobody sends you a message about it.
Reeve Monitor asks the questions in this post again, on a schedule:
- all nine checks every hour, on up to three apps
- whether the app is up, every 60 seconds
- a message when a result changes, so a table that opened last night reaches you before a stranger does
- a monthly report of what it saw
Reeve Care also keeps a copy of your Supabase database. That is the second line of the right-hand column above, done for you.
- an encrypted copy of your Supabase database every night, kept where your project cannot reach it
- each copy verified before it counts, by counting the rows in every table
- a one-click restore when you need one
- your uploaded files as well, once you connect a Storage credential
- everything Monitor does
A table a stranger can read is a thing a check finds. A migration that ran the wrong way, or an agent with access to your database, empties the table instead, and that is what it looks like from the inside.
What to check once, today
What to do
- Sign in to Supabase and open your own project. The account is yours even if your builder created it, and the dashboard is where every answer below lives.
- Read the lock on every table under Authentication → Policies. A table with row level security disabled hands its rows to anyone holding the key that is already in your app, and a policy permitting everybody counts as disabled.
- Open Settings → API Keys and find out which of your values are publishable and which are secret. If a secret one has ever been in your app, rotate it with Supabase before you take it out of the code.
- Look at your storage buckets. A bucket marked public lists every file in it to anyone who asks, including the files your app never shows.
- Keep a copy of the database somewhere your project cannot reach, because nothing in the list above would bring a deleted table back.
Start with the table locks, because that is the one on this list a stranger can already be using. If you would rather work through the whole thing as a list, the 10-minute security checklist covers it and the other settings worth reading in a newly launched app. Is Supabase secure takes on the other question people arrive with, which is whether any of this was a good idea.
FAQ
What is Supabase in simple terms?
It is where your app keeps everything it has to remember, running on servers somebody else looks after. Your users and their passwords, the rows behind every list your app shows, and the files people upload all live in your Supabase project. It is built on Postgres, a database that has been in production use since the nineties, with a login system, file storage and a way for your app to ask for data straight from the browser added around it.
Is Supabase a database?
It contains one, and it is more than one. The database is Postgres and it is the part people mean when they say Supabase. Around it sit three other services your app may be using: Auth for signing people in, Storage for uploaded files, and Edge Functions for code that runs on Supabase servers rather than in your visitor browser. Your dashboard lists more than those four, and you can leave the rest alone until something needs it.
Did my app builder choose Supabase for me?
Almost certainly, yes. Lovable, Bolt, v0, Cursor, Replit and Windsurf all reach for a hosted Postgres the moment your app needs to remember anything, and Supabase is the common answer. You may have clicked one button marked connect a database, or your builder may have created the project without asking. Either way the account is yours and you can sign in to it, which is the first thing worth doing.
Which parts of Supabase security are my job?
Supabase runs the servers, the Postgres version, the updates, the encryption on their disks and the login system itself. Yours are the rules: which rows each visitor may read, which files in a bucket are public, who holds your keys and which key is in your app, and whether a copy of your data exists anywhere your project cannot reach. Nothing in the first list fails quietly. Everything in the second can be wrong for months while your app works perfectly.
Is my Supabase data private by default?
It depends on how each table was made. Supabase documentation states that the Table Editor enables row level security for you when you create a table in the Dashboard, and that when you create a table with SQL you enable it yourself. A builder writes SQL, so tables it made for you arrive with that setting off. Until it is on and a policy is written, Supabase says anyone holding your publishable key can read and write every row in that table, and your publishable key is in your app where anybody can read it.