What to do with your database before you go live
The database from your build environment was made for trying things; the database of your product has to keep things. That difference lies in four things: who owns it, whether there is a backup you have restored once, who is allowed in, and what you never put in it. None of the four is technically hard, and all four are skipped until the first time something is lost.
This article goes through them, with the one action that makes the difference: making a backup and restoring it onto an empty system, before there is real data in it. After that you know it can be done, and that is the only moment when you can learn it calmly.
What is different about a database that is live?
The content belongs to someone else. As long as you are the only one entering data, a database is a scratchpad: if it goes wrong, you start again and nobody notices. As soon as a stranger enters something, an account, an order, a message, it has become their data and your responsibility. Lost is then really lost, and it is not your loss but theirs.
On top of that, a database that is live can be reached from the internet, and not only from your build tool. The settings that were fine in a trial environment are exactly the settings you do not want on a live system: anyone may read, the password is in the code, the backup is off because there was nothing to keep.
And it grows. A trial database has ten rows. A live database has thousands after a year, and by then there is bookkeeping in it too: invoices, payments, data that carries a retention obligation. What you set up now determines how easy it still is to keep track of in a year.
- From scratchpad to storage at the moment a stranger enters something.
- Reachable from the internet, with the settings of a trial environment.
- It grows, and bookkeeping ends up in it.
Who owns the database, and can you leave with it?
The database your build tool created is often on an account of the tool, or on an account created through the tool that you cannot access directly. Check that first. Can you log in to the database service yourself, separately from the tool, and do you see your data there? Then it is yours. If not, you create an account at a database service yourself, set up an empty database and have the tool point to it. The documentation of your tool describes how.
Choose a service you can leave again with an ordinary export: a file another service can read in without help from the first. Most well-known services offer that, and it is the question you ask before you choose, not after. A database you cannot get out of is not a database but a lease.
Write down where the database is, under which account, and where the login details are kept. That seems excessive until the moment you no longer remember after three months.
- Can you log in to the database service without the tool and see your data.
- Choose a service with an ordinary export; ask about it beforehand.
- Write down where it is and under which account.
Which backup do you really need to make?
The backup you have restored once. A backup you have never restored is a hope; you do not know whether it is complete, whether it is readable, and whether you know how to do it at the moment you are panicking. That is why the most important action in this article is not making the backup but restoring it, onto an empty database, and checking that everything is there.
Do it now, with the ten rows from your trial environment, because then a mistake costs nothing. Make a backup through the service itself or through an export, create a second empty database, restore the backup onto it, and look. If it works, you know two things: that it can be done, and how long it takes. That second one is just as important later as the first.
Then turn on an automatic backup, daily, with a retention period of at least a few weeks, so that you can also go back to a point before a mistake you only discovered after a week. Most services have that as a setting; with some it is only in a paid plan, and then that plan is worth the money.
- A backup is only a backup once you have restored it.
- Practise it now, with trial data, on an empty database.
- Automatic, daily, kept for a few weeks.
Who is allowed in, and how do you limit that?
A database service usually has two kinds of access: the key with which your project itself reads and writes, and the rules that determine what a visitor may see through your project. The first does not belong in your code but in the settings of your host, as an environment variable. The second is where most mistakes are: an AI that wants to build fast likes to set the rules to allow everything, because then it works.
So check, per table, who may read and who may write. A user may see their own data, not someone else’s. A visitor without an account may perhaps see a public list, but not change anything. What exactly that is called differs per service; the documentation of your service has its own chapter on it, and the health check on this site has a point for it.
Test it from outside. Log in as a second test account and try to open the data of the first. If that works, there is work to do. If it does not, you have checked something most makers assume.
- The key of your project: in the settings of the host, not in the code.
- The rules per table: who reads, who writes. Never allow everything.
- Test it with a second account, from outside.
What do you never store?
Passwords in readable form. Every serious login service stores an unreadable derivative, and if your build tool made its own login system, check that it does the same. Full payment details: you leave those with a payment service and store at most a reference. Copies of identity documents, unless a law requires you to. And anything you do not need: every piece of data you keep, you also have to protect, and the cheapest data is the data you do not have.
Also think about what you keep on people who do not enter anything. Visitor data, device addresses, logs: it is tempting to keep everything because you can. As soon as you store an email address or something similar, you need a privacy statement that says what you keep and why, and then you have to actually do it that way.
A good question for every column: if this is out on the street tomorrow, what is the damage? If the answer is large, you do not store it or you encrypt it.
- No readable passwords, no payment details, no identity documents.
- Nothing you do not need.
- The question per column: what is the damage if this is out on the street.
How long do you keep what, and when do you throw it away?
That depends on what it is. Under Dutch law, data that belongs to your bookkeeping, such as invoices and payments, falls under a retention obligation of seven years, and ten for real estate; the Belastingdienst (the Dutch tax authority) describes which data that is. So you do not throw that away, not even when a customer asks, and you say so in your privacy statement.
For the rest the opposite applies: do not keep it longer than necessary. An account that has not been used for a year, logs that are three months old, an order that has been completed and whose invoice is kept elsewhere: a clean-up rule may exist for those. Better still, that rule exists from the start, because cleaning up a database with five years of history is work nobody dares to do any more.
Keep the two kinds apart, in separate tables if you can. Then when you clean up, you know exactly what may go and what must stay.
- Bookkeeping: seven years, real estate ten; that is Dutch law.
- The rest: no longer than necessary, with a clean-up rule from day one.
- Two kinds, two places.
In what order do you arrange it?
First ownership: can you get to the database yourself, separately from the tool, and can you get out with an export. Then the backup: make it, restore it onto an empty system, turn on the automatic one. Then access: the key out of the code, the rules per table, the test with a second account. Then the content: what you do not store, and how long you keep what. That is an afternoon for a small project, and it is the afternoon that makes the difference between a prototype and something you dare to give to a stranger.
Do it before there is real data in it. With ten trial rows every step is an exercise, and with a thousand real rows it is an operation. Whoever has seen the cliff once knows that this is the step that is skipped most often and comes back hardest.
And once it is done: write down in the file next to your project where the database is, how you restore a backup and what the rules are. For you, six months from now.
- Ownership, backup, access, content. In that order.
- With trial data, before there is real data in it.
- Write it down, for yourself later.
Sources
Checked on 5 September 2026. The retention periods come from the Belastingdienst; the rest is working method, and the documentation of your database service takes precedence over this article.
Further reading
Three places that connect to this.
From first prompt to tax return.
The platform opens later. Questions or comments can be sent to info@basestep.io.