You built an app. It works. People are using it, filling in forms, uploading photos, creating accounts. And somewhere in the back of your mind is a question you never quite answered: where does all of that actually go?
It is a fair question, and not a naive one. When you build with AI coding tools or a no-code platform, the machinery that stores your data is deliberately hidden so you can move fast. That is helpful on day one. On day two, when you start thinking about backups, exports, or what happens if a tool shuts down, the hidden parts suddenly matter a lot.
This post answers "where does my data live?" in a plain, physical way. Not the theory of databases, but where your specific app keeps things and who is holding them. Think of it as a map. Once you can see the map, everything downstream (exporting, backing up, securing) gets a lot easier. It builds on the broader picture in understand the app you built with AI, and it pairs well with frontend, backend, and API in plain English if the words "backend" and "server" still feel fuzzy.
The three places your data can live
Your app's data almost always lives in some mix of three places. Keeping them separate in your head is the single most useful thing you can do.
1. The database. This is where structured data lives: rows and columns, like a very fast spreadsheet. Every user account, order, comment, task, or booking is a record in the database. If you can imagine it as a row in a table ("Jane, jane@email.com, signed up March 3"), it is probably in the database.
2. File storage. Databases are bad at holding big files, so images, PDFs, videos, and other uploads usually go somewhere else: a file storage bucket. The database often keeps a small note that says "the profile photo for Jane is stored at this address," and the actual image sits in storage. Two different places, working together.
3. The hosting account. This is the account that holds the other two. Your database and your storage do not float in space. They sit inside an account with a provider (your no-code platform, a cloud service, or both). Whoever controls that account controls access to everything inside it. This is the part people forget, and it is the part that matters most for ownership.
Here is the same idea as a quick reference:
| Type | What it holds | Concrete example in your app |
|---|---|---|
| Database | Structured records | User accounts, orders, messages, settings |
| File storage | Uploaded files | Profile photos, receipts, exported PDFs |
| Hosting account | The database and storage themselves | The login that can reach all of it |
A well-built solo app might have all three in one platform, or spread across two or three providers. There is no single "correct" setup, which is exactly why you have to look at yours rather than assume.
How to find your database and what's inside it
You do not need to run any code to find your database. You mostly need to know where to look in the tools you already use.
If you built on a no-code platform, the database is usually a tab or panel inside the same dashboard. It might be called Data, Collections, Tables, Records, or Content. Open it and you will typically see a list of tables with names like users, orders, or posts. Click into one and you will see rows. That is your database. You are looking at the real thing your app reads from and writes to every time someone uses it.
If your app was built with AI coding tools, the database is often a separate service that the app connects to (a managed database provider is common). In that case, finding it means finding the login for that service, not digging through code. A useful trick: look for the connection settings, environment variables, or "integrations" section of your project. The name of the database provider is usually sitting right there.
What you are trying to learn at this stage is small and specific:
- What tables exist, in plain terms (accounts, orders, messages, and so on)
- Roughly what kind of information each one holds
- Which provider is actually storing it
You do not need to understand the schema like an engineer. You are drawing a map, not rebuilding the territory.
Where uploaded files and images actually go
If your app lets anyone upload anything (a photo, a document, a logo), those files are almost certainly not in the database. They are in file storage, and file storage is easy to overlook precisely because it works silently.
To find it, follow an upload. Pick a file you know a user added, then look in your platform or project for a storage area. It may be labeled Storage, Files, Assets, Media, or Buckets. Inside, you will usually find the actual files, often with long automatic names, grouped into folders.
Two things are worth noticing here:
- File storage can live somewhere different from your database. Your records might be on one provider and your images on another. That is normal. It just means your "map" has two pins, not one.
- Files can quietly become the biggest and most sensitive part of your data. A folder of uploaded ID documents or customer receipts carries more risk than a table of usernames. Knowing where that folder is (and who can reach it) is the whole point of this exercise.
You are not securing anything yet. You are just confirming the second place your data lives so nothing is invisible to you later.
Who holds the keys: your account, the tool's account, or both
Now the ownership question. Finding your data is one thing. Knowing who controls the account it sits in is another, and it is the part that decides how much you actually own.
Broadly, there are three situations:
- You control the underlying account. Your database or storage lives in a cloud account that is registered to you, with your billing and your login. The platform uses it, but you hold the keys. This gives you the most control and the most responsibility.
- The tool controls the account. With many managed no-code and AI platforms, your data lives inside the vendor's own account. You interact with it through their dashboard, but you never receive a direct, independent login to the storage underneath. It works well, and for many builders it is a reasonable trade. It also means your access depends on that vendor's account, terms, and continued existence.
- A mix. Very common. The database might be in a cloud account you own, while file storage or authentication lives inside the tool. Different pieces, different keyholders.
None of these is automatically bad. A hosted setup where the vendor holds the account is not inherently unsafe, and it is not a sign you did something wrong. What matters is simply knowing which situation you are in, because it changes your answers to three later questions: can I export this, can I back it up independently, and what happens if this tool disappears? This is the heart of what we mean by owning your stack, and it is why the Own your stack guide exists.
Why this matters for backups, export, and security later
Right now this might feel like housekeeping. It becomes concrete the moment something changes.
Backups. You can only back up data you can reach. If your database lives in an account you control, exporting a copy is usually straightforward. If it lives entirely inside a managed tool, your backup options are whatever that tool offers, no more. Knowing this in advance is the difference between a calm afternoon and a bad surprise.
Export and lock-in. "Where does my data live?" and "how hard is it to leave?" are the same question wearing different hats. Data that sits in a database you own can often move with you. Data locked inside a proprietary format inside a vendor's account is stickier. We go deep on the how in export your data out of a no-code platform; for now, just notice that today's map predicts tomorrow's exit.
Security and personal data. The moment your app stores real information about real people (names, emails, uploaded documents, anything that could identify someone), you have taken on responsibilities. Where that data lives, and who can reach it, is the first fact any sensible security review starts from. We are not going to hand you compliance rules here, because that belongs in dedicated posts and depends on your situation. If you want the entry point, start with does my app handle personal data, and treat the Secure and Ship Responsibly pillars as where the conservative, detailed guidance lives. This is educational, not legal advice; for anything involving payments, logins, or sensitive personal data, verify with a qualified professional before you rely on it.
The short version: you cannot back up, export, or protect data you cannot locate. Locating it is step one, and you are doing it right now.
A quick inventory: map where your app keeps everything
Here is a small, do-it-today exercise. Grab a note and answer six questions about your own app.
- Database. Where is it, and what provider holds it? List the main tables in plain words.
- File storage. Do users upload anything? If so, where do those files go, and is it the same provider as the database or a different one?
- Accounts and keys. For each of the above, is the underlying account registered to you, or to the tool? Where would you log in to reach it directly, if you could?
- Personal data. Which of these places holds information about real people? Flag those; they carry the obligations covered in the Secure and Ship Responsibly pillars.
- Access. Who else can reach any of this (co-founders, contractors, the platform)?
- The "what if" line. For each place, jot down what you would do if that tool shut down tomorrow. If the answer is "I don't know," that is useful too; it tells you where your ownership is thinnest.
You do not need perfect answers. Even a rough map turns a vague worry ("I'm not sure where my data is") into a short list you can act on. When you are ready to turn that list into something structured, the ownership audit walks you through inventorying it properly.
In Plain English
What it means: Your app's data lives in up to three separate places: a database (structured records), file storage (uploads like images and PDFs), and the hosting account that holds them both. They are not the same thing, and they may sit with different providers.
Who it helps: Any non-technical builder who shipped an app with AI or no-code tools and has never actually seen where the data goes, or who is uneasy about what they own.
When to use it: Before you think about backups, exports, switching tools, or security. This is the map you draw first; everything else reads from it.
What to do next: Run the six-question inventory above on your own app. Write down the provider, the account holder, and the "what if this shuts down" answer for each place. Flag anything that holds personal data.
Your next step
You do not have to change anything today. Just make the invisible visible. Spend fifteen minutes filling in the six-question map, then use the ownership audit to record it somewhere you can return to. When you want to see how this fits the bigger picture of understanding and owning what you built, the Understand what you built guide and Own your stack are the natural next stops. Knowing where your data lives is the quiet foundation everything else stands on.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.