If your app needs to remember anything a person did after they close the tab, yes, you need a database. And if you built the app with Lovable, Base44 or Bolt, you almost certainly have one already, because the builder added it the first time you asked it to save something. The question that actually matters is different: do you know where your data lives, and is it the kind of place that keeps it?
That second question is the one that bites. Most “my app lost my data” problems are not caused by a missing database. They are caused by data that was saved somewhere temporary, by an app that looked fine on a laptop and quietly forgot everything once it was published.
What a database actually is
A database is a separate program whose only job is to store information and hand it back, reliably. Not “probably.” Reliably. The power goes out, the data survives. Two people save at the same moment, both saves land correctly. A million records, and finding one takes a few milliseconds.
Your app never touches the stored data itself. It asks the database for every trip that belongs to user 47, or tells it to save a new trip for user 12, and the database does the finding, the writing and the backing up, and makes sure two requests never trample each other. Every serious app you use, from your bank to your email, works this way.
The alternative is what a first AI-built app often does without telling you: it writes your data into a plain file sitting on the computer that runs the app. That works while one person is using it on one machine. It stops working the moment either of those things changes.
How to tell in one minute whether yours needs one
Ask yourself three things about your app.
- Does anything a person types, uploads or creates need to still be there tomorrow?
- Do different people need to see different things, like their own list and not everyone’s?
- Will you ever want to look at what people did, count them, or email them?
A yes to any of those means you need a database, and you should find out where yours is. A no to all three means you do not. A calculator, a single-page brochure site, or a one-shot generator that shows a result and forgets it can live happily without one. Adding a database to an app like that only adds a bill and one more thing to keep safe.
A trip planner I built started as the second kind of app. You typed a city, it wrote a day-by-day plan, and the plan vanished when you closed the tab. That was fine for a demo, and a problem the first time someone spent twenty minutes planning a week in Lisbon and wanted it back after lunch.
You probably already have one. Here is where it is.
Each builder keeps data in a slightly different place.
Lovable turns on its built-in backend, called Cloud, by default, so most projects never need a separate account. It runs on the same open-source foundation as Supabase, which means you get a real database, login and file storage without setting anything up. Your data is in there, billed through your Lovable credits.
Base44 gives every app an integrated database. Open the Dashboard in your app editor and click Data. Every table in your app shows as a card, and inside each one your records look like spreadsheet rows. Base44 calls a table an “entity.” You can add, edit or delete records by hand there.
Bolt creates a database automatically when your project needs one, or when you ask it to, and it can use Supabase instead if you prefer. Look for the Database settings in your project to see your tables.
Claude Code and Codex are different. They are not app builders with a backend attached. They are assistants that write the files of your project, and they put your data wherever you tell them, or wherever they guess if you do not say. That is why a first Claude Code app often saves to a file on disk. Nothing is wrong with the assistant. It simply did the smallest thing that satisfied “save the trip.” If you are not sure what yours did, ask it in plain words where the app keeps what people create, and whether that is a real database or a file on the server. The answer decides everything below.
Why saved data goes missing, and what the fix looks like
Saved data disappears in exactly two ways. Either it was written somewhere temporary, because modern hosting runs your app on short-lived workers that answer a request and then vanish, taking any file they wrote with them, or two people saved at the same moment and the second write silently replaced the first.
A database handles both, because it lives in one permanent home away from the workers and it lines up simultaneous writes so nobody’s change is lost. If your app is inside Lovable, Base44 or Bolt, that is already true for you. If Claude Code built it and it told you “a file,” it is not. The fix is a move, not a patch: the app keeps its screens and its logic, and the saving and loading get pointed at a real database instead of the file.
You will see two words next to any database, SQL and NoSQL: SQL keeps data in tables with fixed columns and links between them, NoSQL keeps each record as one flexible document, and if you can draw arrows between the nouns in your app, SQL fits. Inside a builder you do not choose, and in Claude Code the usual answer is a managed Postgres database, which is SQL.
A database stores what belongs to whom, but it only knows “whom” if your app has login, so the two are almost always built together, login first.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 12, Where Do I Put All This?. The first lesson is free, no card.
In the next ten minutes, do this. Open your app as a stranger would, create something, close the tab, and come back an hour later. If it is still there, your data has a home. If it is not, find your builder in the section above, or ask your assistant where it put the data. Then decide whether your app is the kind that needs to remember.