Skip to main content
Projects that store data get a real PostgreSQL database — not an in-browser mock, not a shared table with other people’s rows in it. The agent designs the schema, writes the migrations, and connects your app to it; your app talks to Postgres the same way any production application does.

​
What this means for your app

  • Data survives restarts, sleeps, and publishes — it’s a real database.
  • The agent can inspect and query it while building (“show me the bookings from this week”) and seed it with example data when useful.
  • Schema changes (new tables, new columns) are applied as migrations as your app evolves — just ask for the feature; the schema follows.

​
Isolation you can rely on

Your project gets its own database and its own database role, and the boundary is enforced by Postgres itself: a query that targets another project’s data is refused by the database with a permission error. This isn’t an application-level filter that could be forgotten — it’s the database’s own access control.

​
Good to know

  • Connection pooling is handled at the platform layer; you don’t manage connections.
  • Query results and statement sizes have generous but real limits; the agent paginates large reads.
  • Point-in-time recovery exists at the platform level and protects against data loss. Self-service named backups and restores are not yet available — if you need a restore, contact support.
  • If you export your project to GitHub, the app’s database code is standard Postgres — it runs against any Postgres instance you point it at.