> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Database

> View and edit your app's data in the Database view: browse tables, edit records, run SQL, change your data structure, and open the tools around your database.

The **Database** view shows your app's data and lets you edit it directly, without writing code. A database is where your app keeps the information it needs to remember, such as users, orders, or messages, in tables. Each row is one record and each column is one detail about it, similar to a structured spreadsheet.

To open the view, go to **More → Database**. You need edit access to the project to open the view and change records.

When your database runs low on resources, the view shows a notice that your app is under high load. See [Fix a slow database and choose the right capacity](https://docs.lovable.dev/features/database-performance.md).

## Add a database to your project

Every project can use the [built-in backend](https://docs.lovable.dev/features/cloud) (Cloud), which includes a managed PostgreSQL database. Describe the data your app needs in the project chat, and Lovable creates the tables and their structure for you. For example, tell Lovable:

```text wrap theme={null}
I want a place to keep track of my clients with their name, email, phone number, and notes. I also need a way to track deals, including which client it's for, the value, the stage it's in, and when I expect it to close.
```

Until the project has a database, the **Database** view shows a card describing what a database stores, with an **Enable** button. Enabling the database also adds user accounts and file storage to the project, because the three services run together.

Lovable creates the database in a region that cannot be changed afterwards. See [Choose where your project's data is stored](https://docs.lovable.dev/features/cloud#choose-where-your-project-data-is-stored) for how that region is decided.

> [!NOTE]
>
> Lovable cannot enable the database from inside a [draft](https://docs.lovable.dev/features/drafts.md), so ask in the main version of your project. Every draft then uses the same database as your project. Lovable adds the tables and columns you ask for in a draft when you accept the draft. Accepting a draft never removes or renames a table or column. See [Add database tables and columns from a draft](https://docs.lovable.dev/features/drafts.md#add-database-tables-and-columns-from-a-draft).

## View tables and data

The **Database** view lists your project's tables with an approximate row count for each. Click a table to browse and edit its records. Tables populate as soon as your app saves information.

The list also includes any database views your app uses. A database view shows data drawn from one or more tables, and you can read it but not edit it.

## Edit records

Open a table to view and edit its records. Double-click a value to edit it in place. You can also:

* **Filter**: add one or more column filters. Available operators depend on the column type, for example equals or contains for text, greater than or less than for numbers, and before or after for dates.
* **Add row**: opens a form based on the table's structure. The database fills in some columns itself, such as IDs and timestamps, so the form leaves those out.
* **Edit row**: opens the full row for editing. Editing a row works only in tables with a single primary key, the column that identifies each row.
* **Delete**: select rows and delete them. The button names how many rows you selected, and Lovable asks you to confirm. Deleting rows cannot be undone.
* **Export CSV**: download the table's records as a CSV file. The file contains every row that matches your current filters, not only the page you see. For a copy of the whole database, see [Export your database](https://docs.lovable.dev/features/database-backups.md#export-your-database).
* **Refresh**: reload the table after your app writes new data. The view does not update live.

You can show 10, 25, 50, or 100 rows per page.

The **Database** view has no import option. To load data from a file, such as a CSV export from another tool, attach the file in the project chat and ask Lovable to add the rows to a table.

> [!WARNING]
>
> Edits apply directly to your project's database, the same database your published app uses.

## Read your form submissions

Ask Lovable for a form that visitors use to reach you, such as a contact, booking, or quote form. Lovable creates a table for it and saves each submission as a row. Lovable tells you the table's name in the project chat. To read the submissions, go to **More → Database** and open that table.

Lovable sets the table's access rules so that visitors can submit the form but cannot read, change, or delete a submission. Anyone with edit access to the project can read the whole table.

To get each submission by email as well, tell Lovable which address to send it to. See [Can Lovable email me when someone submits a form?](https://docs.lovable.dev/features/custom-emails.md#can-lovable-email-me-when-someone-submits-a-form).

You can have submissions go to a service you already use instead of a table, such as a customer relationship management (CRM) system. Name the destination when you ask for the form, or ask Lovable to change it later.

For a form that delivers elsewhere, Lovable does not create a table. Lovable offers to store a copy as well, so a failed delivery does not lose the submission.

## Find the tools around your database

In the **Database** view, select **Manage** to open the tools around your database:

* **Jobs**: scheduled background tasks in your app. See [Jobs](https://docs.lovable.dev/features/jobs.md).
* **SQL editor**: run your own queries against the database. See [Run SQL queries](#run-sql-queries).
* **Edge functions**: the server-side code your app runs. See [Edge functions](https://docs.lovable.dev/features/edge-functions.md).
* **Backups**: the daily backups you can restore. See [Back up, restore, and export your app's database](https://docs.lovable.dev/features/database-backups.md).
* **Policies**: the rules that decide which rows each user can see or change. See [Row level security (RLS) policies](https://docs.lovable.dev/features/database-access.md#row-level-security-rls-policies).
* **Settings**: the database itself, rather than the data in it.

From **Settings** you can [resize the instance or add storage](https://docs.lovable.dev/features/database-performance.md), [check its location](#check-where-your-database-is-hosted), [export the database](https://docs.lovable.dev/features/database-backups.md#export-your-database), or [pause and remove it](https://docs.lovable.dev/features/database-pause-remove.md).

## Check where your database is hosted

To see the region your database runs in, go to **More → Database**, select **Manage**, then **Settings**. The **Database location** row shows that region and the PostgreSQL version your database runs. The row names the region the way the hosting provider does, for example **Europe (Frankfurt)** for a database in Europe.

The region is set when the database is created and cannot be changed afterwards. Existing projects cannot be moved between regions. To choose the region for a project before you create its database, see [Choose where your project's data is stored](https://docs.lovable.dev/features/cloud#choose-where-your-project-data-is-stored).

## Run SQL queries

For direct database access, open the **SQL editor**: in the **Database** view, select **Manage**, then **SQL editor**. Write your query, then click **Run** or press **⌘/Ctrl + Enter**.

The editor autocompletes table and column names from your database. Results appear in a table below the query. If a query fails, the error message appears in its place. Click **Clear** to empty the editor.

If a query contains a destructive statement such as `DELETE`, `DROP`, `TRUNCATE`, `ALTER`, or `UPDATE`, Lovable asks you to confirm before running it.

When you run SQL in the SQL editor, you change your database directly. Lovable does not save that SQL as a [migration file](#how-lovable-changes-your-database-structure) or add it to the record of migrations in your database. Your migration files therefore do not include changes you make in the SQL editor.

> [!TIP]
>
> You rarely need SQL. For most changes, describing what you want in the project chat is safer, because Lovable records each structure change as a migration file. See [How Lovable changes your database structure](#how-lovable-changes-your-database-structure).

## How Lovable changes your database structure

When you ask for a new table, column, or access rule in the project chat, Lovable makes the change. Lovable also updates the type definitions in your app's code, so the code matches the database.

Lovable records each change as a migration file in your project's code, under `drizzle/migrations/`. A migration file is an SQL file that describes one change to the database structure. Your code therefore carries the full history of how your database was built.

Lovable uses Drizzle, an open-source tool for database migrations, to create and apply migration files. Some projects use an earlier setup, where Lovable writes each migration file under `supabase/migrations/` instead. In projects that moved to Drizzle, Lovable leaves the earlier files under `supabase/migrations/`.

Lovable refuses changes that could break your published app:

* Dropping or renaming a table or column
* Changing a column's type
* Adding a required column without a default value

Instead, Lovable reaches the same result by adding to your database, for example by adding a new column and copying the data over. The old column stays in place.

To let Lovable make such a change directly, set **Execute backward incompatible database migrations** to **Ask each time** or **Always allow** in your [agent permissions](https://docs.lovable.dev/features/cloud#tool-settings-and-defaults). With **Ask each time**, Lovable shows you the SQL and asks for your approval before it applies the change.

Lovable maintains the `drizzle` folder, including `drizzle/schema.ts`, and the `drizzle.config.ts` file in your project's code, so leave them as they are.

## How migrations run

Each time Lovable changes your database structure, it applies your migration files, the SQL files that record each change, in a migration run.

Lovable applies migrations on a database connection that can change your database structure and create access policies on `storage.objects`, the table behind your storage files. Your app's own code uses different connections.

This section covers projects whose migration files are under `drizzle/migrations/`. On the earlier setup, with files under `supabase/migrations/`, Lovable applies only the change you asked for. If someone adds a migration file to `supabase/migrations/` through a synced [Git repository](https://docs.lovable.dev/integrations/git-sync-overview), Lovable applies the file only when you ask.

In projects with files under `drizzle/migrations/`, three things about how Lovable runs migrations can be unexpected:

* Lovable can also apply earlier changes in your project's code that it has not applied yet, not only the change you asked for.
* When one statement fails, Lovable applies none of the changes in the run.
* When Lovable reports a timeout, Lovable can still apply the change afterwards.

Someone can add a migration file to your project's code through a synced Git repository. Lovable applies that file the next time it changes your database structure, together with the change you asked for, even if the file was added weeks earlier.

Lovable applies a migration file from Git only when Drizzle's migration journal lists it. The journal, `drizzle/migrations/meta/_journal.json`, is the list Drizzle uses to find migrations to apply. A migration file's journal entry must have a date after the last migration Lovable applied.

A developer who creates a migration with Drizzle's command-line tool, drizzle-kit, gets the journal entry automatically. If someone copies an SQL file into `drizzle/migrations/` without a journal entry, Lovable does not apply the file.

Lovable applies all pending migrations together, in one run. If one statement fails, Lovable discards every change from that run and applies nothing, so your database stays as it was before the run.

A timeout is different from a failed statement. A timeout means Lovable stopped waiting for the result, and Lovable can still apply the change afterwards. Before you ask for the same change again, check whether Lovable applied it, so Lovable does not apply it twice. For example, ask Lovable in the project chat:

```text wrap theme={null}
Was my last database change applied?
```

Lovable applies migrations one run at a time. When two runs overlap, Lovable starts the second run only after the first one finishes.

Lovable also records each applied migration in your database. The record in your database is separate from the migration files in your code. If you edit or delete a migration file afterwards, the changes Lovable already applied stay in your database.

## Supported PostgreSQL extensions

A PostgreSQL extension adds a capability to your database, such as scheduled jobs or vector search. Your project's database supports a fixed set of extensions:

| Extension | Use it for |
| - | - |
| `pg_cron` | Scheduled jobs |
| `pg_net` | HTTP requests from the database, for example to call an edge function |
| `pg_trgm` | Fuzzy text search and similarity matching |
| `vector` | Embeddings and vector similarity search |
| `btree_gist`, `btree_gin` | Extra index types, such as exclusion constraints |
| `unaccent` | Accent-insensitive search |
| `fuzzystrmatch` | Phonetic and edit-distance string matching |
| `postgis` | Geographic and spatial data |
| `pgmq` | Message queues |

Every database also comes with `plpgsql`, `pg_graphql`, `pg_stat_statements`, `pgcrypto`, `uuid-ossp`, and `pgsodium` preinstalled.

To enable a supported extension, ask Lovable in the project chat or run the statement in the [SQL editor](#run-sql-queries):

```sql theme={null}
CREATE EXTENSION IF NOT EXISTS pg_trgm;
```

Lovable refuses a `CREATE EXTENSION` statement for any other extension before it runs. The refusal applies when you ask in the project chat, run SQL in the **SQL editor**, or send SQL through the [Lovable API](https://docs.lovable.dev/integrations/lovable-api.md) or the [Lovable MCP server](https://docs.lovable.dev/integrations/lovable-mcp-server.md).

The **SQL editor** shows an error that lists the supported extensions. The API returns a `403` response with the error type `unsupported_extension` and a message that lists the supported extensions.

When you ask for a feature that would need an unsupported extension, Lovable builds it with plain SQL instead. For example:

* Instead of `citext`, Lovable uses a `text` column with a unique index on `lower(column)`.
* Instead of `hstore`, Lovable uses a `jsonb` column.
* Instead of `http`, Lovable makes the request with `pg_net`.

Extensions already installed in your database keep working. Projects that use your own [Supabase](https://docs.lovable.dev/integrations/supabase.md) project instead of the built-in backend are not affected.

## FAQ

> [accordion] Can two projects share one database?
>
> No. Every project on the built-in backend gets its own isolated database, and one project cannot read another project's database. If several apps need to share one database, connect them to the same external [Supabase](https://docs.lovable.dev/integrations/supabase.md#can-multiple-lovable-projects-share-one-supabase-project) project instead.
>
> Lovable warns you when you pick a Supabase project that another Lovable project already uses, because projects that share one Supabase project overwrite each other's secrets. See [Can multiple Lovable projects share one Supabase project?](https://docs.lovable.dev/integrations/supabase.md#can-multiple-lovable-projects-share-one-supabase-project).

> [accordion] Can I install a PostgreSQL extension that isn't on the supported list?
>
> No. Your project's database supports a fixed set of PostgreSQL extensions. Lovable refuses `CREATE EXTENSION` for any other extension in the project chat, the **SQL editor**, and the API. When a feature would need an unsupported extension, Lovable builds it with plain SQL instead, and extensions already installed keep working. See [Supported PostgreSQL extensions](#supported-postgresql-extensions).

> [accordion] Does a failed statement undo the whole migration?
>
> Yes. Lovable applies all pending migrations in one run, and a failed statement discards every change in that run. See [How migrations run](#how-migrations-run).
>
> * Write your SQL without `BEGIN`, `COMMIT`, or `ROLLBACK`. Lovable rejects migrations that contain them.
> * A few statements cannot run inside a transaction, such as `CREATE INDEX CONCURRENTLY`.
> * On the earlier setup, with files under `supabase/migrations/`, [contact support](https://docs.lovable.dev/introduction/support-policy.md#contact-support) before you rely on a full rollback.

> [accordion] Does the migration history match my migration files?
>
> Not always. Your database records which migrations ran, and your project's code keeps the SQL. The two records are separate, so editing a file afterwards does not change what Lovable already applied.
>
> Projects with files under `drizzle/migrations/` keep the record in a Drizzle table, where each row stores a SHA-256 hash of the file as it was when it ran. A file you change later no longer matches its hash. Projects on the earlier setup keep the record in the Supabase migrations table, which stores a version and a name but no hash.

> [accordion] How do I record a migration I already ran in the SQL editor?
>
> Not by running the SQL again. A second run can fail, or change your data a second time.
>
> [Contact support](https://docs.lovable.dev/introduction/support-policy.md#contact-support) so they can compare your database with the migration record first.

> [accordion] Can I undo a migration without restoring a backup?
>
> Sometimes. You can reverse many structural changes with a new migration, for example by adding a column or a policy back. A new migration does not recover deleted data unless you have another copy of it.
>
> Do not assume that each migration leaves a restore point behind. Before a destructive change, [contact support](https://docs.lovable.dev/introduction/support-policy.md#contact-support) to check which recovery options your project has, and see [Restore a daily backup](https://docs.lovable.dev/features/database-backups.md#restore-a-daily-backup).

> [accordion] Is there a size limit for a migration?
>
> No maximum is published, which is not a promise that any size succeeds: [contact support](https://docs.lovable.dev/introduction/support-policy.md#contact-support) before you submit a very large migration. Lovable creates a migration from the SQL text you give it, not from a file you upload, so no file size limit applies.

> [accordion] Does pushing to my repository apply migrations?
>
> Not at the moment you push, but the file does not sit there either. Lovable applies a pending migration file from your repository the next time it changes your database structure, alongside the change you asked for. See [How migrations run](#how-migrations-run).
>
> A merged pull request is a code review, not an approval to change your database. Check for pending migration files before you ask Lovable for a new one.
>
> Dates decide the order. Lovable skips a migration file dated earlier than the last one it applied, with no error and no second attempt. Check the date on any file you add yourself.

> [accordion] Can Lovable apply only the migration I approved?
>
> No. Lovable creates migration files, can update supporting files, and can apply earlier pending migrations in the same run.
>
> Your approval covers the SQL shown in that request, not the whole run.

> [accordion] Does a timeout mean my migration was not applied?
>
> No. A timeout means Lovable stopped waiting for the result, and Lovable can still apply the change afterwards. See [How migrations run](#how-migrations-run).
>
> Check whether the change reached your database before you ask for it again, so Lovable does not apply it twice.

> [accordion] Can two migrations run at the same time?
>
> No. Lovable applies migrations one run at a time and starts a second run only after the first finishes. See [How migrations run](#how-migrations-run).
>
> Your app stays up during a run. A migration that changes a table does lock it until the whole run finishes, so reads and writes to that table wait for it.

> [accordion] Are failed migrations retried?
>
> Some paths retry on their own after a server error or a timeout. Do not retry a failed migration yourself until you know whether Lovable applied it, because a second run can apply the same change twice.

> [accordion] Does the SQL editor run my statements in one transaction?
>
> Not necessarily. The [SQL editor](#run-sql-queries) sends all of your SQL as one request, but on most projects several statements are not guaranteed to run in one transaction. After an error or a timeout, earlier statements can stay saved.
>
> **Cancel** stops the wait in your browser. The query keeps running in the database. Check your data before you run the SQL again.

> [accordion] What are the drizzle files in my project's code?
>
> Lovable uses them to record and apply changes to your database structure. The `drizzle/migrations/` folder contains one SQL file per change, and `drizzle.config.ts` and `drizzle/schema.ts` are configuration files Drizzle needs. Leave them as they are. See [How Lovable changes your database structure](#how-lovable-changes-your-database-structure).