Your app's database

Every Vaulter app gets a database, and you never have to set it up. The moment your app needs to store something, the storage is already there, in your app's own isolated space with privacy rules built in.

It is automatic

When you ask for a feature that needs data, "let users save their bookings", the agent creates the right tables as part of building the feature, and declares who should be able to see each one. You do not design schemas or write queries. You describe what the app should remember, and the data model follows. Schema changes are applied as migrations that run automatically when they are saved.

The Database panel

Open the Vault tab and choose Database. It is a full workbench:

• Tables. Browse every table with its row count. Click into one to page through rows (100 at a time), add rows with a form, edit rows inline, and filter by any column with real operators (equals, not equals, greater and less than, contains, is empty). A Who can see this button shows the exact privacy rules protecting each table. From here you can also import a CSV as a new table, and download any table as a CSV.
• SQL Editor. Run queries directly when you want to look at your data your own way.
• Logs. Your app's real runtime output while you build: console messages, requests, and errors from the preview. The server-side page covers reading them.
• History. The full record of every schema change, with per-migration status, and the error text if one failed.

Images and other files your app displays live in their own tab, Vault → Storage; see Files and storage.

Let the agent work with your data

You can also ask the agent in chat:

• "Add ten sample products so I can see how the page looks."
• "Delete the test bookings I made yesterday."
• "Show me every user who signed up this week."

Self-healing migrations

Occasionally a schema change fails for a temporary reason, like timing. Vaulter treats failure as a state to recover from, not a verdict: failed migrations retry automatically, and a success clears the failure on its own. Clearly permanent errors, like a genuine mistake in the change, stop immediately and surface a plain-language message naming the migration and the reason, so you can fix it and try again. Until then, the Database panel shows a banner rather than letting a broken schema publish.

Guardrails

A few protections are always on:

• Destructive operations you author yourself, like dropping a table or a delete with no filter, require explicit confirmation before they run.
• The agent is never allowed to drop tables.

Where your data lives

By default, your data lives in a private, per-app space on Vaulter's managed backend, so there is nothing to configure and privacy rules are enforced for you. Two different apps can each have their own todos table without ever colliding.

To understand who can read which data once your app has users, read How data privacy works. It is the most important thing to get right before you publish an app with real users.

Frequently asked

Can I import data I already have?

Yes. The Database panel imports CSV files into a table, and you choose the privacy class as part of the import. For data living in a Supabase project you own, connect it directly instead of copying.

Do the preview and the published app share the database?

Yes, one database per app. Rows you create while testing are real, so clear test data before launch (ask the agent, or delete from the panel).

Can the agent delete my data?

The agent can edit data you ask it to, but it is never allowed to drop tables, and destructive operations you author yourself require explicit confirmation. Treat panel deletes as permanent.

Do I need to know SQL?

No. Browsing, filtering, and editing are all point and click, and the agent handles the data model. The SQL editor is there for when you want it, not because you need it.