Skip to main content
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.

Add a database to your project

Every project can use the built-in backend (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:
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 for how that region is decided.
Lovable cannot enable the database from inside a draft, 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.

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.
  • 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.
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?. 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: From Settings you can resize the instance or add storage, check its location, export the database, or pause and remove it.

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.

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 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.
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

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. 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, 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:
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: 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:
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 or the Lovable MCP server. 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 project instead of the built-in backend are not affected.

FAQ

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 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?.
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.
Yes. Lovable applies all pending migrations in one run, and a failed statement discards every change in that run. See 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 before you rely on a full rollback.
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.
Not by running the SQL again. A second run can fail, or change your data a second time.Contact support so they can compare your database with the migration record first.
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 to check which recovery options your project has, and see Restore a daily backup.
No maximum is published, which is not a promise that any size succeeds: 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.
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.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.
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.
No. A timeout means Lovable stopped waiting for the result, and Lovable can still apply the change afterwards. See How migrations run.Check whether the change reached your database before you ask for it again, so Lovable does not apply it twice.
No. Lovable applies migrations one run at a time and starts a second run only after the first finishes. See 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.
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.
Not necessarily. The SQL editor 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.
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.