This question comes up in almost every skeptical demo I've given. Someone watches an AI builder spin up a working app in a few minutes and their first real question, once the initial "huh, that's fast" wears off, is some version of: okay, but is there actually a database in here, or did it fake it? Fair question. Here are the ones that come up in order, roughly, of how a person's skepticism evolves once they start poking at it.
Is there a real database, or is the demo just faking it with sample data?
There's a real database. What varies is which one, and that variance is the part worth understanding before you build anything you plan to keep. A prototype AI builder that's optimizing for "watch this work in ninety seconds" will often reach for SQLite — a single file on disk, zero setup, perfectly capable of running a real app for a single user. A builder optimizing for "this needs to survive contact with actual traffic and multiple tenants" reaches for Postgres, because SQLite's file-locking model starts to hurt the moment more than one process needs to write at the same time. Ask which one you're getting. It's a completely reasonable question to ask a sales page or a support chat, and if nobody can answer it clearly, that itself tells you something.
What database engine does it actually use?
Postgres, in the platforms built for anything beyond a toy. It's the boring, correct answer, and boring is what you want here. Postgres gives you row-level security so tenant A's rows are invisible to tenant B's queries even if application code has a bug, real foreign keys, real transactions, and twenty years of "someone already hit this edge case and fixed it" behind it. The interesting failure mode isn't "which SQL dialect" — it's builders that start on SQLite for speed and never migrate off it as usage grows, because migrating a live database with users on it is unglamorous work that's easy to keep deprioritizing. If you're evaluating a builder for something you intend to run for years, ask what happens to the database as the app scales past one user. The honest answer involves a migration path; the evasive answer involves the word "scalable" repeated without specifics.
Can I see my own data, or is it locked inside a black box?
You should be able to, full stop. A table browser, a query console, an export button — some way to look at the rows without going through the app's own UI. This is less a technical question than a trust question. An AI builder that generates a schema you can't inspect is asking you to trust code you didn't write and can't audit, which is a much bigger ask than "trust me, the UI button works." The tools that get this right treat the underlying data as yours by default, not as an implementation detail they're protecting you from.
Does it handle schema changes when I ask for a new feature?
This is where it gets genuinely hard, and where a lot of AI builders quietly fall short. Adding a column is easy. Adding a column, backfilling existing rows with a sane default, updating every query that touches that table, and doing it without losing data that's already there — that's a migration, and migrations are one of the few places where "the AI wrote code that compiles" isn't the same as "the AI wrote code that's safe to run against production data." A builder worth using treats a schema change as its own reviewable step, not something silently bundled into a bigger feature request. If you ask for "add a due date to tasks" and get back a diff that only touches the frontend, be suspicious — the database didn't get the memo.
Does it model relationships properly, or does everything get flattened into one big JSON blob?
Both patterns exist, and which one you get matters more than most people realize going in. A relational schema — separate tables for users, orders, and order items, joined by foreign keys — lets you ask questions the app's original UI never anticipated: "which customers bought X and Y together," "what's our refund rate by product category." A single denormalized JSON blob per record is faster to generate and fine for a genuinely simple app, but it turns every future "just add a report" request into a re-architecture. Ask to see the schema, not just the running app. If every table looks suspiciously like `{ id, data jsonb }`, you're looking at a builder that optimized for getting something on screen fast and punted the actual data modeling.
| Pattern | What it's good at | Where it breaks |
|---|---|---|
| Proper relational schema (separate tables, foreign keys) | Reporting, joins, data integrity, future features you haven't thought of yet | Slightly more upfront generation time; harder for a naive prompt to get exactly right on the first pass |
| Single JSON blob per record | Speed to first demo, simple single-entity apps (a note-taking tool, a basic form) | Any query that spans records, any relationship, any report — all become application-code workarounds instead of SQL |
| Hybrid (core fields in columns, flexible extras in a jsonb column) | Apps with a stable core shape plus user-defined custom fields | Requires the builder to know when to use which — the sloppy version just puts everything in the jsonb column |
What happens if I outgrow the amount of data it was built for?
Depends entirely on whether the underlying engine was built for concurrency in the first place. This is the SQLite-versus-Postgres question again, wearing a different hat. An app on SQLite handling a few hundred rows for one user feels identical to an app on Postgres handling the same load — the difference only shows up once you add concurrent writers, larger row counts, or the kind of analytical query that benefits from indexes and query planning. If your app is genuinely single-user and low-volume forever, this may never bite you. If you're building something you hope has customers, ask the scaling question before you have the problem, not after a support ticket teaches you the answer.
Is my data actually isolated from other users on a shared platform?
This is the one I'd push hardest on, because it's invisible until it fails. Multi-tenant platforms that store everyone's data in the same database need a real isolation boundary — row-level security policies enforced by the database itself, not just application code that remembers to add a `WHERE user_id = ?` clause to every query. The difference matters because application-code isolation fails silently: one missed filter in one endpoint and tenant A can suddenly see tenant B's rows. Database-enforced isolation fails loudly, because the query returns nothing even if the application code forgot the filter. Ask, specifically, whether tenant isolation is enforced at the database layer or trusted to application code. Most people asking about "can it handle a real database" are actually asking this question without knowing the vocabulary for it yet.
Can I export everything and leave if I want to?
You should be able to get a full export of your actual data — not a screenshot of your app, not a PDF of a report, the underlying rows in a format you could load somewhere else. A builder that makes this hard is telling you something about how it thinks about the relationship. The honest version of "AI builder" means the platform generated the code and schema on your behalf; it was never supposed to mean the data stops being yours the moment it lands in a table you didn't personally provision.
The database is the part nobody demos, which is exactly why it's the part worth asking about before you sign up for anything.
None of this is exotic engineering. It's the same due diligence you'd apply to any backend-as-a-service or hosting decision — the AI part just makes it easy to forget to ask, because the demo is so good at hiding the plumbing. Ask what engine, ask to see the schema, ask about migrations, ask about isolation. If the answers are specific, you're probably fine.
