How the DYPAI backend works: database, APIs and workflows
DYPAI has its own backend platform for the apps you build. It is not a new database engine: each project gets a PostgreSQL database, while DYPAI provides the authentication, API and workflow runtime around it. Files are stored in Cloudflare R2. You can manage the same project visually in Studio or through MCP from a coding agent in your IDE.
That distinction matters. "Built-in backend" can mean anything from a database connection to an entire application runtime. Here is what an app actually uses in DYPAI, and where you still make design decisions yourself.
Your app's data: PostgreSQL per project
Each project has its own PostgreSQL database. You can create tables and relationships in the visual database editor, run SQL, or ask a connected agent to inspect the schema and apply a migration through MCP. Your application code does not need to provision a separate database account before its first table exists.
This is PostgreSQL, not a proprietary query language. It is also not a Supabase project under the hood: DYPAI operates its Postgres infrastructure and connects its own services to it. The database documentation covers schemas, limits and backups, including the fact that automatic daily backups are a paid-plan feature.
Users, files and the path into your data
DYPAI includes signup, login, sessions and roles. The client SDK handles authentication and sends the user's token with API requests; your endpoints decide which roles may call them. The auth documentation shows the available methods and access model.
