What is a database and does my app have one?

The word database sounds like something only engineers deal with, but the idea is homely. If your app remembers anything at all between visits, that memory lives in a database. Knowing whether you have one, and where it is, tells you a lot about what you actually built.

What a database actually is

Picture a very well organised filing cabinet. Instead of loose papers, it holds neat grids called tables, and each table holds one kind of thing: a table of users, a table of orders, a table of messages. Each row in a table is one record, one customer or one order, and each column is a detail about it, like a name or a date. A database is simply this cabinet plus a fast, reliable way to ask it questions: find every order from last week, add this new user, change that email address. It is built to do this quickly and safely even when many people are using the app at once, which is the part a plain spreadsheet cannot manage. When an app needs to remember something, this is where it goes.

How to tell if your app has one

You can work it out without opening any code. Ask yourself a few plain questions about your app. Can someone create an account and log back in later to find their things still there? Does it save what a visitor types, a booking, a comment, a saved draft, and show it again next time? Does it take payments or keep a list of orders? Does what one person sees differ from what another sees? A yes to any of these means information is being remembered between visits, and that memory has to live somewhere: a database. If your app is purely fixed pages that read the same for everyone, with perhaps a contact form that just emails you, then it very likely has no database at all, and that is a simpler, cheaper thing to run.

Why it matters to you

Knowing you have a database changes what you need to care about. First, cost: a database is a running service, so an app with one usually costs more to keep online than a plain website, and that cost grows with use. Second, safety: your database holds the information you most need to protect, customer names, emails, maybe payment details, so how it is locked down matters far more than how the pages look. A badly configured database can let strangers read everything in it, which is one of the more serious problems AI-built apps quietly carry. Third, ownership: the data in your database often cannot be rebuilt if lost, so knowing where it lives and who controls the account matters more than owning the code itself.

Where your database probably lives

If you built with a tool like Lovable, Bolt or Replit and your app remembers anything, there is a good chance it set up a database for you behind the scenes, very often on a service called Supabase. You may never have chosen it consciously; the builder made the decision. The practical thing to do is find out. Look in your builder for a mention of a database, a data section, or a connected Supabase project, and check whose account it sits in. If it is in the builder's account rather than one you control, that is worth resolving, because the data is the part you least want to be renting. If you cannot work out where your data lives at all, that uncertainty is a good reason to get a second pair of eyes on it.