Your data

Your app's data lives in a PostgreSQL database that is yours from the first minute. The Database page has three views.

Schema

A diagram of your tables and how they link. Each box is a table; each line is a foreign key, a column that points at a row in another table (an order points at the customer who placed it). Primary keys are marked; they are the id every other table uses to refer to a row.

Data

The rows themselves, table by table. Useful for checking what a build actually stored, or fixing a typo in one record.

Enums

Fixed lists of allowed values, like an order status that can only be pending, paid, or shipped. Use one whenever a column should accept a short, closed set of values.

Changing the schema

Describe the change in the assistant panel: "add a notes column to orders", "create a table for coupons with a code and an expiry date." Insight turns it into a migration, a small SQL script that is checked and applied. The panel reports what changed: tables created, columns added, warnings.

Migrations are the safe way to change a live database because each one is recorded and applied exactly once. Renaming or dropping a column that existing pages use will break those pages until they are rebuilt, so prefer adding over renaming while the app is in use.

Where DontCode fits

Every project gets its own isolated schema; the users table is managed by the platform and protected. Migrations run through a validation pipeline that blocks dangerous statements, and a failed migration is rolled back rather than half-applied.