Database
Every DYPAI project comes with its own PostgreSQL database. Full Postgres β not a watered-down variant β with the same types, constraints, and SQL you'd use anywhere else. Dedicated to your project, isolated from everyone else's.

Three ways to manage it
| Ask your AI | "Create an orders table with total, date, and customer_id." β the MCP handles the SQL. Fastest for most tasks. |
| Visual editor | Click through the Database tab to create tables, edit columns, and browse rows. Good for quick tweaks. |
| SQL editor | Run any SQL directly. Good for complex migrations or queries the UI doesn't cover. |
You'll switch between them depending on the task. For a straightforward CRUD, the AI is usually the fastest. For inspecting data, the visual editor. For anything the AI gets wrong or an edge case, SQL.
Security model
Security in DYPAI is enforced at the endpoint level, not at the database level. There is no row-level security (RLS).
That means: the database trusts the workflow calling it. Your endpoints are the gate. If an endpoint filters by ${current_user_id}, only that user's rows come back. If an endpoint doesn't filter, a caller with access to that endpoint sees everything.
This keeps things simple β you reason about access in one place (the endpoint), not in two (the table and the endpoint). But it means every endpoint you build is responsible for its own filtering. More on this in API Builder: Endpoints.
Never expose raw tables
Don't build endpoints that return entire tables without filtering. Always scope queries to the current user, the requested record, or an explicit role check.
Schemas you can use
Your project database has a few schemas with different rules:
publicβ your schema. Full read/write. This is where your tables go.systemβ user auth, roles, endpoints metadata, agent memory. Read-only for your queries. Safe to join from (e.g.LEFT JOIN system.users).storage/authβ internal plumbing. Read-only. Don't write to them.
The visual editor only shows public by default. The SQL editor lets you read from the others.
Backups
Automatic daily backups run for every project. If you need to restore, request it from the dashboard. Backups are kept for 7 days on Free, longer on higher plans.
Limits
| Free | Paid | |
|---|---|---|
| Database size | 500 MB | Up to 100 GB |
| Concurrent connections | 20 | Up to 200 |
| Query timeout | 30s | 30s |
| Backup retention | 7 days | 30 days |