Export is a feature, not a support ticket
A database dump is not your application. Real portability means schema, data, storage bytes, auth users, and policies — in a bundle that boots elsewhere.
Most clouds will let you leave. Eventually. After a support ticket, a
pg_dump, and a weekend of discovering everything the dump left out.
That is not portability. That is a database dump with extra steps.
What a real export contains
scribase export produces a bundle, and a bundle is not a .sql file. It
includes:
- Schema — tables, indexes, functions, extensions.
- Table data — streamed with
COPY, chunked and checksummed. - Auth users and identities — with IDs preserved, so JWTs and foreign keys stay valid and nobody has to reset a password.
- Storage objects — the actual bucket bytes and metadata, not just a reference to files you can no longer reach.
- RLS policies, grants, and roles — the rules that make the data usable.
- A manifest with SHA-256 evidence, so you can verify the bundle before you trust it.
Why we ship the escape hatch
Lock-in is a business model that depends on your inertia. We would rather depend on being the best place to run your backend. If we stop being that, the export button is right there, and it works.
Portability also disciplines the product. When "leaving" is a first-class, tested command, every feature has to survive the question: does this still make sense in the exported bundle? That question keeps the whole system honest.
Try it on the home page, then read how the same verification powers restore.