A database that refuses to lose your data
You've watched one schema change take out half the app. Orbit runs on Postgres from the first field you add, so changing your mind never means starting over.
The wall
The demo was fast. The database underneath wasn't.
“What worked for a demo breaks in production.” You added one field and buttons you never touched stopped working. The data underneath was shaped for a screenshot, not for the day users arrive, save things that matter, and expect them to still be there tomorrow.
How it works
One canvas. A whole backend. Data that survives.
You draw the shape of your app once. Orbit turns it into a Postgres database, a REST API, and a migration path that protects what's already there.
A schema you can see, backed by Postgres
Tables, fields, and links on a canvas. Every table becomes a Postgres table with a time-ordered key. Every link becomes a foreign key, with the delete rule you choose.
One canvas generates the whole backend
From the same schema, Orbit generates Postgres tables and indexes, row-level security, a typed query layer, and a REST API with an OpenAPI schema. You draw it once, and the backend follows.
Migrations that refuse to lose your data
We never run a DROP on your app's database. Delete a field, the column and its data stay. Rename one, your old data stays put. Anything destructive stops for your approval, and anything unsafe is blocked before it can run.
Honest edge: a rename won't auto-move your old data. It stays safe in the old column until you migrate it.
Where it fits
Draw it once. The whole app reads from it.
Your data model isn't a side panel. The screens in Mockup bind to it, and the logic in Workflows reads and writes it. One shape, one source of truth, across the app.
Build on a database you can trust
Describe your app. Watch Orbit stand up the schema, then keep shaping it as you grow.