# 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.

Source: https://scribase.com/blog/export-is-a-feature-not-a-support-ticket

By Scribase, 2026-09-10.

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](/#export-demo), then read how the same verification
powers [restore](/docs/backups).