What Is a Database? A Plain-English Explanation

AI Build South Africa

A fundamentals guide, written for someone whose AI agent writes the actual database queries, not someone learning SQL from scratch.

Quick answer

A database is where your app's actual information lives: user accounts, orders, messages, anything that has to still be there after you close the tab. It's separate from your app's code, which is instructions, not data. Ask your AI builder for a "users" or "orders" table and it creates a real, structured store, organised into tables (like a spreadsheet), rows (one entry each) and columns (one field each), that many people and your live app can read and write to at once. Lovable and Bolt.new both provision this as a Supabase Postgres database; Base44 uses its own built-in store, defined as entities rather than hand-written SQL tables. Either way, the data persists independently of any single chat session with your AI agent.

Tools for this build

POPIA Compliance Checker

For when your database is holding real customer information.

Custom Prompt Builder

Turns your task, in your own words, into a prompt with clear limits for your AI coding agent.

PayFast Webhook Generator

Writes a payment record to your database once a webhook confirms it.

The one-sentence version: your app's information, kept separate from its instructions

Your app's code tells it what to do: how to display a page, what happens when someone clicks a button. None of that is where the actual content lives. When someone signs up, places an order, or sends a message, that information has to be stored somewhere that survives after they close the browser tab, and outlives any single AI chat session where you asked for a new feature. That somewhere is the database. Change the code and the app looks or behaves differently; change the database and what the app actually knows changes.

This split matters practically the first time you ask your AI builder to "add a comments section" or "let users save their favourites." The AI agent isn't just writing a form, it's creating a real, structured place for that data to live, one that has to exist correctly before the feature can work at all.

A spreadsheet vs. a real database

A spreadsheet

One person edits it at a time:

No enforced structure, easy to overwrite, doesn't scale past one user

A database

Built for many readers and writers at once:

Enforced structure, safe under real simultaneous use, is what your live app actually runs on

AI Build · aibuild.co.za

Where you'll actually see this: tables, rows, columns

Most databases your AI builder creates, whether through Supabase or Base44, organise data the same conceptual way a spreadsheet does, even though what's running underneath is far more capable. A table holds one kind of thing: a "users" table, an "orders" table. A row is one specific entry in that table: one user, one order. A column is one field every row in that table has: an email address, an order total, a date. Ask your AI agent for a new field on an existing feature and you're really asking it to add a column. Ask it to store a new kind of thing entirely, and you're asking for a new table.

Why your AI builder needs a real backend to hold one

A database has to run somewhere with real, persistent storage, not inside your browser tab. This is exactly why Bolt.new, which before Bolt Cloud had no built-in backend until you connected a Supabase project, now provisions a Supabase backend through Bolt Cloud by default once your app needs one: without a backend, "save this order" means nothing beyond the current session. Lovable provisions a Supabase Postgres database by default through Lovable Cloud, giving you real SQL tables your AI agent writes queries against. Base44 takes a different route: your data model is defined as entities, described declaratively rather than as hand-written SQL, with Base44's own runtime handling storage, validation and queries behind that layer. Different mechanics, same underlying job: a place for your app's real information to persist. Our guide to the folder structure of an AI-built app shows where that backend sits in the file tree.

The one rule that matters here too: who can see which rows

A database being real and persistent doesn't automatically mean it's private. By default, a table that anyone's request can read is exactly that, readable by anyone who can reach it, not just the user it's about. Row Level Security (RLS) is the mechanism that fixes this: a rule, enforced by the database itself, that only lets a given request see or change the rows it's actually allowed to. Neither platform locks data to its owner automatically. Supabase requires you to set RLS policies explicitly on Postgres tables, off by default until you turn it on; Base44 requires the same kind of explicit rule per entity, a read/create/update/delete permission set to public, authenticated-only, owner-only or admin-only, and doesn't default new entities to owner-only on its own. This is the same underlying category of mistake this site's own guide to why you can't put an API key in the frontend covers for secrets: a database with no access rules is a much larger version of the same exposure, every row instead of one key.

Not every database looks like a spreadsheet

The table/row/column model covers what you'll build on Lovable, Bolt.new or Base44 almost all of the time, but it's worth knowing it's not the only shape a database can take. Some systems store loosely structured documents instead of rigid rows, others store simple key-value pairs for fast lookups. None of that changes what matters for a first build: your data lives somewhere real, separate from your code, and the access rules on it are your responsibility to check, not something to assume your AI builder set correctly by default.

Where to go next

See the file tree a database connection actually produces: React Folder Structure Explained for AI-Built Apps.
The same "who can see this" question, applied to secrets instead of rows: Why You Can't Put an API Key in the Frontend.
When a connected database stops answering, starting from the symptom: Why Is My AI-Built App Not Working?

Not affiliated with the platforms we write about

AI Build South Africa is an independent resource. We're not endorsed by, or an official partner of, PayFast, Yoco, Peach Payments, Ozow, Meta, Lovable, Base44, Bolt.new or Anthropic. We do participate in affiliate and referral programmes with some of these providers, including Base44. See our Disclaimer for the full disclosure and our Terms of Service for the wider terms.

Frequently asked questions

What's the difference between a database and a spreadsheet?

A spreadsheet is a file one person edits at a time, with nothing stopping you from typing a date into a price column. A database enforces structure (a price field only accepts a number) and lets many people, or your entire live app, read and write at once without one edit overwriting another. A spreadsheet is a document. A database is a system built to stay correct under real, simultaneous use.

Where does my database actually live if I'm using Lovable, Base44 or Bolt.new?

For Lovable and Bolt.new, it's a Supabase Postgres database, provisioned automatically once your app needs one (Lovable Cloud and Bolt Cloud both do this by default). For Base44, it's the platform's own built-in data store, defined as entities rather than hand-written SQL tables, with no separate service to connect. Either way, your AI agent creates and edits the structure through prompts. You're not writing SQL by hand, but the data is real, persisted, and outlives any single chat session.

What is Row Level Security, and why does it matter for my data?

Row Level Security (RLS) is a rule, enforced by the database itself, that decides which rows a given request is allowed to see or change. Without it, anyone who can reach your database's API can potentially read every user's data, not just their own. Supabase requires RLS policies to be set explicitly on Postgres tables, off by default; Base44 requires an equivalent per-entity permission rule (public, authenticated-only, owner-only or admin-only) and doesn't default a new entity to owner-only on its own. Either way, this is the single setting most responsible for a real data leak, not a bug in your app's own code.

Is my database automatically backed up?

Don't assume so without checking. Backup policy differs by plan and platform, and it's not something your AI agent decides or controls, it's a setting on the underlying service (Supabase or Base44's own infrastructure). Check the specific plan you're on rather than assuming a free or entry tier includes the same backup schedule as a paid one.

Can two people view or edit the same data at the same time?

Yes, that's a core reason a real database exists instead of a shared file. Multiple users, or your live app and an admin panel, can read and write the same underlying data at once, and the database handles keeping it consistent. This is exactly what a spreadsheet or a hardcoded array in your frontend code can't safely do once more than one person is using the app.

Do I need to learn SQL to use a database in an AI-built app?

Not to get started. Your AI agent writes the queries, the table structure, and the relationships between tables based on your prompts. Knowing roughly what a table, row and column are, covered on this page, is enough to direct that work and check whether what it built matches what you actually asked for. Reading actual SQL becomes useful once something breaks and you want to understand why, not before.