Building

Database

Every project's private Postgres: how it's provisioned, how to use it, and how to look inside.

Updated 21 Sept 2026

Every project gets its own Postgres database with its own role and password, created the first time the preview starts. No setup, no shared tables, no way for one project to read another's data.

What you get

  • A dedicated database on a Postgres 16 cluster reserved for project databases (separate from Qyant's own).
  • A role that can only access that database.
  • DATABASE_URL in your .env, pointing at it. The same database is used by the preview and by deployments, so data you enter while building is there in production.

The template's wiring

The starter project already talks to the database:

  • lib/db.ts — a pg connection pool built from DATABASE_URL, with a query<T>(text, params) helper.
  • lib/items.ts — creates an items table on first use and exposes listItems / addItem.
  • app/api/items/route.ts — a route handler the home page's form posts to.

Ask the model for tables and it will follow the same pattern: SQL through the pool, tables created if missing, server-side code only.

Working with schema

The template uses plain SQL rather than an ORM, which keeps generated code readable and reviewable. Typical prompts:

Add a calls table (customer_id → customers, notes, called_at) and a function to list calls for a customer.

We're storing money as floats — change amounts to integer cents everywhere.

Review schema changes carefully before accepting; see Reviewing changes. Adding an ORM (Prisma, Drizzle) is possible — ask for it — but it adds a migration step to every schema change.

Connecting from outside

The connection string in .env is reachable only from inside Qyant's network. There is no public database endpoint today. To inspect data, ask the model for an admin page or an export endpoint, or query through a route handler.

Backups and lifetime

Project databases live as long as the project. Deleting a project drops its database. Qyant's nightly infrastructure backups cover project databases, but they're a disaster-recovery measure, not a point-in-time restore you can trigger — export anything you can't lose.

Limits

There are no per-row or per-table quotas. Storage is subject to fair use on all plans; if you're building something data-heavy, talk to us.