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." — your AI client edits the schema over MCP. 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.
Behind the scenes, the AI drives the database with the MCP tools execute_sql, apply_migration (schema changes), get_app_tables (inspect the schema), and manage_roles. The local @dypai-ai/mcp package adds manage_database and bulk_upsert for bulk loads from your filesystem.
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 are a paid-plan feature — the Free plan has no automatic backups. On a paid plan you'll find them under Database → Backups, where you can download any recent backup. There's no in-app "restore" button: you download a backup and re-import what you need. Retention is a single global window (~7 days, env-configured) — it's not tiered by plan.
See Backups for the full flow.
Limits
| Free | Paid | |
|---|---|---|
| Database size | 500 MB | Up to 100 GB |
| Query timeout | 30s | 30s |
Database storage is an org-plan limit, shared across every app in your workspace, and it's tracked on the project Usage page (Observe → Usage). Exceeding it blocks writes until you free up space or upgrade. Connections are served from a shared pooled backend (PgBouncer), so you don't manage a per-project connection cap directly.