The business app we build ourselves, anken.ai, keeps its data in Supabase (the development log is here).
We are a contractor. There is nobody here whose job is looking after servers. We still wanted our own app, and that was the condition we chose under. In case it is useful to anyone in the same position, here is why we picked it — and what we find frightening about it.
What Supabase is (in three lines)
- A service that takes a database called PostgreSQL and makes it usable straight over the internet
- Login, a place to put files such as photos, and server-side processing all come with it from the start
- There is a free tier you can start on
Think of it as “a box for a database, plus everything you always end up needing around it” and you are about right.
What worked
1. Inside, it is ordinary PostgreSQL
We think this is the big one.
It is not a proprietary contraption — it is PostgreSQL itself, the same one used everywhere. Which means the SQL we write and the shape of the data can be taken elsewhere.
For a small company that is insurance. If prices go up, if the policy changes, if the service shuts down altogether, we can leave with our data in our arms. Put the other way round: we decided from the outset not to get on anything we could not get off.
2. Permissions can live in the database
This system is built on the assumption that other firms will use it in future. If someone at Company A could see Company B’s jobs, that alone would be the end of it.
Supabase lets you use a PostgreSQL feature called RLS (Row Level Security). The official explanation describes it as “like having a WHERE clause added automatically to every query”.
What matters is that this bites in the database, not in the app. Get the screen code wrong, and the database still says “these rows are not for you” and stops it. With few of us and nobody to review the work, we decided that last line of defence was needed.
3. Not having to build login ourselves
Storing passwords, reset emails, invitations. The kind of thing where, built from scratch, you get some part of it wrong every time — it is there from the start.
4. Types are generated automatically
Type definitions for the code can be generated from the shape of the database. Rename a column, and every screen using that column goes red while you are still typing. On a small team, that stands in for an extra pair of hands.
5. Photo storage and server-side work in the same place
Before-and-after photos go into file storage (Storage). Talking to outside services, and the parts we hand to AI, go into server-side processing (Edge Functions). Having one supplier to deal with is, frankly, a relief for whoever has to manage it.
Pricing (as of 16 August 2026)
This is what the official site lists.
| Free | Pro | |
|---|---|---|
| Monthly | $0 | $25 |
| Database size | 500MB | 8GB |
| File storage | 1GB | 100GB |
| Transfer | 5GB | 250GB |
| Login users | 50,000/month | 100,000/month |
| Server-side invocations | 500,000/month | 2,000,000/month |
| Paused when unused | Paused after one week | Not paused |
Above these sit Team ($599/month) and Enterprise.
For trying things out, the free tier is plenty. But as below, staying on free for real work is another matter.
Prices change. Check the amount as at the time you are reading on the official pricing page.
What we watch
There is no point writing only the convenient half, so here is the rest.
1. Forget to turn RLS on and it is wide open
The official documentation warns about this plainly. Tables in the public schema are exposed through the API, so RLS must be enabled.
Which means the moment you add one table and forget the permissions, that table can be read from outside. The convenience and the danger sit in the same place.
Our rule here is that adding a table and setting its permissions are one job, not two. Even so, we think “have we forgotten one?” needs checking over regularly.
2. The free plan stops after a week
Leave a project unused for a week and it is paused. Fine while you are trying it out, but for real work, paying is the premise. Assume “we can run this for free” and it will take your legs out from under you.
3. Development and production are not separate (this one is on us)
At the moment, the database we work against while developing and the production database are the same one. Only we use it so far, so no harm has come of it, but it will be split before the first customer comes on. It says so on our own list of loose ends.
This is not a Supabase problem. It is a problem with how we have organised ourselves.
4. It is still somebody else’s care
Put data with an outside service and you are exposed to that company’s circumstances. We wrote “it is PostgreSQL, so we can leave” — but that does not mean leaving is no work. Keeping a backup on our own side is something to think about separately.
To anyone in the same position
You want your own business app, but you have nobody to run a server. For a company like that, we think this kind of service is a realistic option.
When deciding, the two things worth looking at are probably these, rather than the number of features.
- When you stop, can you leave with your data
- When you get the permissions wrong, where does it stop
We chose Supabase because it had answers to those two. Not because it has a lot of features.
The company website itself is built differently. That is covered in choosing a server and why we chose Astro.
This piece is an AI draft that a member of our team has worked over. Prices and specifications change, so please check the official information if you are considering it yourself.