# Adding a database

> Where your app keeps its data, and how to add one in a sentence.

An app that forgets everything the moment you refresh is a demo. A database is what makes it a tool.

## When you need one

You need a database as soon as the app keeps something that should survive a page reload:

- Records people create, edit or delete
- Anything one person should see that another created
- Settings, drafts, notes, history, uploaded files

Simple preferences that only matter inside one browser can live in the browser itself. Anything shared needs a database.

## Adding one

Ask in the chat: "add a database and store bookings in it." Automo Build projects use Supabase, and the builder creates the tables your description implies and connects the app.

If you would rather be precise, describe the tables and their relationships:

```
Tables: clients (name, email, phone, notes) and sessions
(client, date, duration, status). A client has many sessions.
```

## What happens to your existing screens

The app keeps working. Screens are rewired to read and write real records, and any sample content is replaced by what is actually stored. Empty tables mean you will see empty states. That is expected.

## Permissions come with it

Tables should come with access rules: who can read, who can write, and whose records they can see. A common default is that data belongs to the person who created it, with staff given wider access. Ask the builder to explain the rules it set, and check them before you go live. See [Roles and permissions](/collaborate/roles-and-permissions).

## Files and images

Uploads can be stored alongside your data. Ask for an upload field, and ask who should be able to see each file.

> [!note] Changing a table after it holds real data is a migration. Ask for it explicitly and keep a backup: see [Versions and restore](/build/versions-and-restore).