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 View Policies button shows the exact privacy rules protecting each table.
• SQL Editor. Run queries directly when you want to look at your data your own way.
• Migrations. The full history of every schema change, with per-migration status, and the error text if one failed.
• Assets. Upload images your app uses, copy their URLs, and delete them.
• Settings. Your app's ID, schema health at a glance, table and row counts, and the backend connection (this is also where bring your own Supabase lives).

There are also Functions, Edge Functions, and Logs sections for apps that grow into them.

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.
• On a connected BYO Supabase project, editing live rows asks for a per-session confirmation first, since Vaulter cannot undo changes to a database you own.

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.