When Does Your App Actually Need a Real Database?

The real test: does this need to outlive the current session?

The question that actually separates "needs a database" from "doesn't" isn't how complex a feature looks, it's whether the information it deals with has to still exist after the moment it was created. A running total shown on screen, a filter applied to content already loaded, a form's own success message, none of that needs to persist anywhere; it exists for as long as the page does and nothing more. The moment a feature has to remember something specific to one visit and show it back later, to that same visitor or a different one entirely, it needs somewhere real to live. This is the same frontend/backend distinction our guide to what a frontend and backend are covers, applied specifically to where data itself lives rather than where logic runs.

The tell in your own prompt: "save," "remember," "my account," "other users see this"

You don't need to think in database terms to notice when you actually need one. If the feature you're describing to your AI agent naturally includes a word like "save," "remember," "my account" or "so other people can see it," you're already describing something that needs to persist, whether or not you've consciously registered that yet. This is worth noticing before you prompt, not after a feature turns out to reset unexpectedly: our guide to what a database actually is covers the table/row/column shape that data will take once it's stored.

Connecting one: what your builder sets up, and what to ask

Most AI website builders now set up a database for you the first time a feature needs one. Some build on Supabase, a standard backend service built on a Postgres database. Others run their own built-in data store, where each kind of data may be called an entity rather than a table. A coding agent works the other way round: you choose the database provider, and the agent writes the code that connects to it. In every case your AI agent creates the actual tables and writes the queries from your prompts; you describe what you're storing, not the SQL.

Once a database exists, ask your AI two things: where it lives (which provider, and which country or region, since that matters under POPIA), and how you'd export the data if you ever moved. Our guide to understanding your AI-generated project structure shows where a database connection usually appears in your project's files.

The one step people skip: access rules, set in the same session you create the table

A table being real and connected doesn't automatically mean it's private. A new table may start readable by any request that reaches it, which means anyone, not just the user it's about. That's the same exposure our guide to why you can't put an API key in the frontend covers for a client-side secret, only larger: every row instead of one key. Every database has its own name for these rules. Supabase calls them Row Level Security policies; a builder with its own data store usually has a permission setting per table or entity, such as public, logged-in users only or owner only. Don't assume a new table starts private. Ask your AI to show you the rule on each table, in plain words, in the same prompt session where you create it, not as a separate task you'll get to later.

Designing a simple schema through prompting, not SQL

Describe what you're storing in plain terms, an order with a customer, a total and a status, and your AI agent produces a reasonable table structure from that description without you needing to know SQL at all. What's worth doing yourself: naming the specific fields your business actually needs in the prompt, rather than a vague request the agent has to guess the details of. "Add an orders table with customer name, total, payment status and date" gets a table matching your actual business; "add a way to track orders" gets the agent's own best guess at what that means.

Not every feature needs its own table

A quick prototype, a single-purpose tool with nothing to remember between visits, or anything genuinely disposable gets nothing from a database connection that adds real setup and real access-rule responsibility for no benefit. Building on one is worth doing the moment a feature actually needs to persist; even where your platform provisions a database by default, a feature that doesn't need to persist shouldn't get a table just because one is available. Adding a database later, once a feature genuinely needs it, costs you nothing compared with starting with one.