evonx

Preview databases

Every API preview gets an ephemeral Postgres with migrations and seed data - isolated from production.

When a preview includes your API, Evonx gives it a database of its own: a fresh, ephemeral Postgres created for that preview, migrated to the current schema and loaded with seed data. Nothing you do in a preview can touch production data.

What you get, automatically

  1. A dedicated Postgres instance spins up alongside the preview — not a shared database, and never your production one.

  2. Migrations run so the schema matches the code being previewed. If the change you're testing alters the data model, the preview database already reflects it.

  3. Seed data loads — realistic sample records (customers, jobs, appointments, whatever your app's domain defines) so screens render with content instead of empty states.

When the preview is cleaned up, its database goes with it.

What this means in practice

  • Test destructively. Delete records, cancel appointments, corrupt a workflow on purpose — the worst case is restarting the preview for a fresh copy.
  • Data doesn't persist between previews. Each preview starts from migrations plus seed data. If a test needs specific records, add them at the start of the session — or ask the AI to extend the seed data so every future preview includes them.
  • Schema changes get exercised safely. A thread that alters the data model proves its migrations by running them here first, before they ever touch your managed production database.

Last updated: September 4, 2026