Guide · Building real features
Adding a database without regret
Get the shape right early — data outlives code.
You can rewrite every line of your app on a Sunday afternoon. You cannot easily un-collect data you stored in the wrong shape, especially once other people's records are in it. That asymmetry is the whole reason to slow down here.
Do you need one at all?
Genuinely ask. If your tool works on data the user pastes in and never needs it again, you don't need a database — and skipping it removes a whole category of hosting, cost, backup and security problems.
If each user only needs their own data on their own machine, browser storage may be enough. If you need one modest shared list, a file might do.
You need a real database when multiple people share data, when data must survive across devices, or when you need to query it in ways a file can't.
Pick the boring one
SQLite for small projects — a single file, no server, genuinely fine for a lot of real apps. Postgres when you outgrow that. Both are decades old, deeply understood by every model, and will not surprise you.
Design the tables before you write code
My app: <one sentence> The things it stores: <list your nouns> The questions it must answer: <"show me a user's notes", "count today's signups", ...> Design the schema. Tables, columns, types, what's required, what's unique, how they relate. Then, importantly: - Which decision here is expensive to change later? - Which of my "questions" would be slow with this design at 100,000 rows, and what index fixes it? - What did you add that I didn't ask for, and why?
The four habits that save you
Never build a query by gluing strings together. Use parameters. This is the single most exploited bug on the web and the fix is one line of syntax.
Store timestamps in UTC. Convert when you display. Always.
Migrations from day one. Even a numbered folder of .sql files. The moment a schema change exists only in your head, production and local start to drift.
Back it up, and restore it once. A backup you have never restored is a hypothesis.
Test the restore before you need it. Discovering your backup is empty during an incident is a specific kind of bad evening.