A database your backend just calls.
SQLite is on from your first build, with migrations in each release and a restore to any moment. Postgres comes with going live.
What you get.
Records, nothing to run.
Your backend keeps JSON records in named collections through the SDK. There is no server to size, connect or patch.
Writes safe to retry.
Every change carries a key. A create sent again with the same key never makes a second record.
Migrations ride with the release.
New SQL files run in name order, each as one transaction, before the release serves.
Postgres when you go live.
Going live adds Postgres beside SQLite, with a connection string for pg, Drizzle or Prisma. Use either, or both.
Back to any moment.
Put SQLite back to any moment in the last 30 days, or to a snapshot. It takes a snapshot of what it replaces first.
A snapshot of the database as it is now is taken first, and kept 7 days.
Restore to Oct 9, 14:00Questions.
SQLite or Postgres?
Start with SQLite: it is the database in build mode, charged per row read and written. Postgres comes with going live, charged per hour of compute while awake, and only Postgres can be reached directly with a connection string. Nothing locks a project to one.
Can I keep using pg, Drizzle or Prisma?
Yes, on Postgres once you go live. Turn its connection string on for an environment and your backend connects with its own driver or ORM.
Can I take my data with me?
Yes. Export the whole database whenever you want: SQLite as a .sql file, Postgres as a pg_dump file. Either loads anywhere else.