Data-Layer Portability: A Proposed BuilderProof Axis for Whether You Can Take Your Database With You (July 2026)

Quick answer

Every AI app builder benchmark in 2026 measures whether you can leave with your code. Almost none measure whether you can leave with your data — the schema, the rows, and the auth users that a shipped app actually runs on. This is a proposal for a sixth-family BuilderProof axis, data-layer portability, with a five-check rubric and a preliminary, documentation-based read of five builders as of July 2026. It is a proposal, not a scored leaderboard: the reads below are drawn from each vendor's own public docs and are flagged for hands-on verification before they enter a versioned benchmark.

Why code portability is not the same as data portability

BuilderProof already scores whether generated code is yours to take. That work lives in our code-portability axis proposal and the code-ownership leaderboard, and it asks a narrow question: can you export the repository and run it somewhere else?

A repository is not an application. A shipped app is code plus a live database: user accounts, orders, uploads, the accumulated state that is the actual business. You can own 100% of the code and still be unable to leave, because the data sits in a managed store you cannot dump, or in a proprietary schema you cannot re-point.

So data portability is a distinct axis with a distinct failure mode. Code lock-in costs you a rewrite. Data lock-in costs you the business. They deserve separate scores.

The proposed rubric (D1–D5)

We propose scoring the data layer on five documented, reproducible checks. Each is graded 0 (no), 1 (partial or undocumented), or 2 (yes, documented) for a 0–10 axis, normalized against the tested panel per the BuilderProof methodology.

• D1 — Documented export. Is there a published path to a full dump of your data (SQL dump, CSV, or an API that returns all rows)?
• D2 — Direct credentials. Can you obtain a connection string and connect an external client, or is access mediated only through the builder's UI?
• D3 — Standard engine. Is the store a portable standard (Postgres, MySQL) rather than a proprietary format you would have to re-model?
• D4 — Auth-user export. Can you export the identity table (users, hashed credentials or provider IDs), not just business rows?
• D5 — Survives departure. If you disconnect the builder, does the data remain accessible in a store you control, or is it stranded on the platform?

D5 is the one most benchmarks skip, and it is the one that decides whether "you own your data" is true in practice.

Preliminary documentation-based reads (July 2026)

These are docs-first reads only, in the spirit of how BuilderProof verifies agency-suitability "against current documentation, not marketing claims." They are preliminary and pending hands-on dumps before any versioned score.

Lovable documents that "your backend lives in Supabase," a hosted PostgreSQL database you access through the Supabase dashboard and SQL Editor, with "your own Supabase account and billing" (Lovable Supabase docs, 2026). The data layer is a standard Postgres you already control, so D2, D3 and D5 read strongly. The honest caveat is on D1: Lovable's own docs note that moving to another backend means "recreate the schema and move data manually" — the export mechanism is Supabase's, not Lovable's.

Bolt.new follows the same bring-your-own-Supabase model, with three connection paths and direct dashboard access to your rows and auth users (Bolt Supabase support docs, 2026). One documented limitation matters for operators: "Bolt's Version History feature currently does not support Supabase database restores," so rollback is your Supabase project's responsibility, not Bolt's.

Replit provisions a managed PostgreSQL database and, critically for D2, exposes "the connection string, storage usage, and connection details" so external clients can connect (Replit SQL database docs, 2026). A standard connection string is the difference between a portable Postgres and a walled garden.

v0 does not ship a managed database at all; its docs frame it as "extensible: use your APIs, databases, and components" (v0 docs, 2026). Data portability is therefore inherited from whatever provider you wire in — Neon, Supabase, or your own — and never depends on v0.

Base44 describes a "managed backend" but, as of July 2026, its public documentation does not specify a full-export path, the engine, or an auth-user dump (Base44 docs, 2026). We score undocumented checks as 1, not 0 — absence of documentation is not proof of lock-in — but it is exactly the gap this axis is meant to surface, and the one to close with a hands-on test.

For the standard against which "portable" is measured, we anchor on Postgres's own tooling: a pg_dump logical backup is the reproducible baseline any Postgres-backed builder should be able to satisfy (PostgreSQL backup docs, 2026).

What this axis deliberately does not claim

Two guardrails, consistent with BuilderProof's neutrality baseline:

1. A managed backend is not automatically worse. Managed data layers trade portability for convenience, and for many projects that trade is correct. The axis measures exit cost, not quality.
2. Docs reads are not scores. Nothing above is a benchmark result. It is the input to one — the reproducible next step is a hands-on dump on each platform, version-stamped, before data-layer portability enters the composite.

If you have run a real export off any of these platforms, that is exactly the evidence this proposal needs. Send it and we will pin it to the test.

BuilderProof editorial team. "Data-Layer Portability: A Proposed BuilderProof Axis for Whether You Can Take Your Database With You (July 2026)". BuilderProof, July 2026. https://www.builderproof.org/benchmarks/data-layer-portability-axis-proposal-july-2026.

@misc{builderproof-data-layer-portability-axis-proposal-july-2026,
  title  = {{Data-Layer Portability: A Proposed BuilderProof Axis for Whether You Can Take Your Database With You (July 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {jul},
  howpublished = {\url{https://www.builderproof.org/benchmarks/data-layer-portability-axis-proposal-july-2026}},
  note   = {BuilderProof, builderproof.org}
}