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

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.

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

Next steps