Supabase is where the data of an internal tool lives. The platform provides a database, user account management and access rules, with no server to administer. For a mid-sized company having its first business tool built, this is the piece that turns a mock-up into software a team can actually use.
This tutorial is written for a managing director or a team lead, not for a developer. It contains no code. It describes the four decisions that commit the company, in the order they come up, and the three traps that get expensive once you discover them after go-live.
Why your prototype loses its data on every reload
A tool generated by artificial intelligence puts a convincing screen on your display within minutes. Buttons respond, forms fill in, the list updates. Then the user reloads the page and everything is gone. Nothing crashed: the information simply had nowhere to go.
That is exactly where the demo stops in my tutorial on building an application with AI. We built a working application live, from the first prompt to going online. And at the moment of showing the result, the line that lands is this one: we are not saving to a database, so as soon as we refresh, the content disappears. The sequence stops on that limit, and this article picks it up from there.
An internal tool that remembers nothing stays a mock-up. As soon as a team has to log leave requests, track field visits or qualify incoming requests, you need somewhere the information survives the tab closing, where two people see the same thing, and where an accidental deletion can be undone.
Build this tool, or buy it?
This question comes up before you open any technical tool at all. A platform that makes building easy also makes it easy to build things that already exist, and that a company will end up paying for twice, once as a subscription and once as maintenance.
I went through that trade-off in a post on choosing between building and buying AI agents, and the conclusion holds as it stands for internal tools. Between 2023 and 2025, the fashion for in-house prototypes faded, technical debt became frightening and the return on in-house approaches disappointed. In many cases the off-the-shelf product remains the better fit, because its vendor iterates faster than you ever will on a subject that stays peripheral to yours.
On our internal tool engagements, this call is settled in a workshop, before the first mock-up. Tandem works with more than 50 companies and around 100 engagements, and the decision not to build is one of the most profitable we have ever delivered.
Step 1, create the project and choose the region
Creating a Supabase project takes about two minutes. You give a name, a database password and a region. The name can be changed, the password can be changed, the region never. It is the one irreversible decision in the whole setup, and it comes before you have understood what it means.
The vendor's regions documentation distinguishes two families. Specific regions name a city: Paris, Frankfurt or Ireland. General regions name a continent, and the vendor writes plainly that its general Europe region also covers London and Zurich, which are not European Union member states.
Choose Paris if your users are in France. Latency will be better and the question of where the data sits settles itself the day a data protection officer raises it. The same documentation is careful to add that choosing a region is a data location control, and that on its own it proves nothing about regulatory compliance.
Step 2, lay out your tool's tables
A database is organised into tables, and a table looks like a spreadsheet tab. Columns describe the nature of the information, rows hold the records. A field visits table will have a date column, a client column, a technician column and a status column. The vocabulary roughly stops there.
The difference with a spreadsheet comes down to three points, and they are the ones that matter to a team. A database refuses inconsistent data instead of accepting it silently. It links tables to each other, so a client is never typed in twice. And it copes with ten people writing at once without anyone overwriting someone else's work.
- List the objects before the screens. A field visit tracker handles clients, sites, technicians and visits. Those four words are your four tables.
- Name the columns in plain English. You will reread this schema in two years, and so will whoever takes the tool over.
- Put a creation date column everywhere. It is useless in the first month, and it saves every investigation that follows.
- Keep documents elsewhere. Site photos and PDFs belong in file storage, the database only keeps a reference to them.
Step 3, close access on every table
Here is the point that separates an internal tool from a data breach. A web tool talks to its database using a public key, and that key lives in the browser of every one of your employees. It is designed to be readable. Anyone who can open a browser console can retrieve it in seconds.
What protects your data is the access policy set on each table, known as row level security. The vendor's documentation on this mechanism says to enable it on every table in an exposed schema, and notes that a new table in the public schema starts with every privilege already granted to all three database roles. In other words, the protection does not switch itself on.
The cost of that omission is documented. Vulnerability CVE-2025-48757, published in May 2025 and rated 9.3 out of 10 for severity, describes applications generated by a build assistant whose tables were readable and writable with no authentication at all. The accompanying survey reported more than 170 affected applications, exposing addresses, phone numbers and payment data. The vendor of the generation tool disputes the classification and places responsibility on its customers, which changes nothing for the company whose data has walked out.
Step 4, connect the tool and store the keys
Your tool connects to the database with two keys that carry completely different status. The public key travels into the browser and can only read what your access policies allow. The secret key ignores every one of those policies and sees the entire database. It belongs nowhere except on a server.
One fresh detail that French tutorials have all missed: the vendor has renamed these keys. Its API keys documentation now describes publishable and secret keys, and announces that the old anon and service_role keys are being deprecated by the end of 2026. A tutorial that sends you looking for the anon key in the interface sends you looking for something on its way out.
The secret key goes into your host's environment variables, never into the code. It is the same reflex described in our go-live tutorial, and it applies to every key in a project.
Two useful follow-ups. Our Vercel deployment tutorial covers putting the tool online and setting environment variables. Our Claude Code guide for non-developers explains how to have the tool's code written and changed in plain language, once the database is in place.
What does the database of an internal tool cost?
The prices recorded in October 2026 on the official grid fit in three lines. They are shown in dollars before tax, so a French company also pays conversion and value added tax on top.
| Plan | Monthly price | Database included | Backups | Pausing |
|---|---|---|---|---|
| Free | $0 | 500 MB, 2 active projects | None | After one week of inactivity |
| Pro | From $25 per project | 8 GB of disk | 7 days | None |
| Team | From $599 | 8 GB of disk | 14 days | None |
The line that matters for an internal tool is the last one. The vendor writes that free projects are paused after one week of inactivity, and bringing one back is a manual action from the dashboard. A tool your team opens every day will never notice. A monthly closing tool, a seasonal campaign tool or an annual stocktake tool will be switched off every single time it is needed.
The absence of backups on the free plan rules out the same usage for another reason. Business data deleted by mistake cannot be recovered, and the cost of that loss far exceeds the few hundred euros a year of the paid plan. For a tool a team genuinely uses, the Pro plan comes to around $300 a year per project, which is considerably less than a business software licence for five people.
What Supabase does not settle for you
The platform covers the technical side. It covers neither compliance nor governance, and it is better to know that before a client or a works council asks the question.
The vendor's subprocessor register, dated June 2026, lists 24 entities, including the hosting providers Amazon Web Services, Google, Cloudflare, Fly.io and Vercel, and OpenAI for language processing. That document has one feature I had not seen on any comparable register: it gives no country at all. Clay's register names 34 with their country, Mistral's names 25 the same way. Here, the question of where the data travels stays open on reading the official document.
These questions belong to the governance of the tool rather than its code. They join those we cover in our article on AI agent security in business, and they come up in the same order: first what the tool touches, then who reaches it, and finally what is left when something goes wrong.
Where should you start with your first internal tool?
Start with the decision not to build. List what the intended tool does, and look honestly for off-the-shelf software that covers it. If the answer is yes, the best database is the one you will never have to maintain.
If the process really is specific to your company, Supabase is a solid choice to carry it, on four conditions that all fit inside the first working day. Take a named European region rather than the general one. Enable protection on every table as it is created. Store the secret key in your host's environment variables. And move to the paid plan as soon as the tool genuinely enters service, for the backups as much as for the absence of pausing.
The rest is learned by doing. If you would rather scope the need before writing the first table, our AI audit is built for exactly that: sorting what deserves a custom tool from what an existing subscription already settles.
