AI App Builder Database Portability (2026): Where Your Data Lives and How It Gets Out

Quick Answer

In 2026, database portability is a different question from code ownership, and the answers do not line up. Exporting a file is not the same as moving a database. Across six builders, the data lands in one of three places. On v0 there is no vendor database at all: you attach Neon, Supabase, or Upstash from the Vercel Marketplace, so the data sits in an account you already own. Bolt.new provisions its own Bolt Database by default but documents a claim path that migrates it into your own Supabase organization. Lovable runs Lovable Cloud on a Supabase foundation, and its docs state plainly that there is no one-click migration from Cloud to a Supabase project you control. Replit runs real PostgreSQL, but only the production database accepts an external SQL client; the development database is scoped so outside tools cannot reach it. Base44 and Bubble are managed stores with per-table file export and no connection string. The table below scores all six on the criteria that decide whether you can actually leave.

Export is not portability

Almost every builder will let you download your data. That is not the question worth asking. A database is rows plus the schema that gives them meaning: column types, foreign keys, constraints, indexes, and the relations between tables. A CSV keeps the rows and throws away everything else. If you land a folder of CSVs on a new platform, you still have to rebuild the schema by hand and re-link every relation before the data means anything again.

Bubble documents this cost precisely without meaning to. Its export supports CSV, JSON, and Newline-Delimited JSON, and it carries a known issue: a date interval field is "exported as descriptive text, although it is stored as a numerical value in milliseconds in the database," so 172,800,000 milliseconds comes out as the string "2 days" (Bubble manual, 2026). On re-import Bubble expects the number again. That is a small, honest example of a general rule: an export is a rendering of your data, and renderings lose things.

So the real criterion is not "can I download my data." It is what is the highest-fidelity way the data can leave, and does anything but me hold the keys.

The three tiers of database portability

Every builder in this comparison sits in one of three tiers:

1. Tier 1, the data is in an account you own. The builder writes to a database you provisioned under your own billing relationship with Neon, Supabase, or similar. Portability is not a feature the builder grants you; it is a property of a service you already control. You can run pg_dump whenever you like, and the builder leaving your life changes nothing about your data.
2. Tier 2, vendor-provisioned but standard, with a connection string. The vendor created the database and holds the account, but it is genuine PostgreSQL and you can point an external SQL client at it. A full dump is available, but through a door the vendor can close.
3. Tier 3, managed store with file export only. The data lives in the platform's own system. You get CSV or JSON out through the dashboard. Schema, relations, and types are yours to reconstruct.

Tier 1 is the only one where portability does not depend on the vendor's continued goodwill.

AI app builder database portability, scored (2026)

Scored against each vendor's own public documentation, August 2026. "Not documented" means the capability is absent from the vendor's public materials at time of writing, not that it is confirmed impossible.

Replit: real PostgreSQL, but the development database is walled off

Replit is the finding most likely to surprise people, because "it is Postgres" is usually treated as the end of the conversation. It is not.

Replit surfaces a DATABASE_URL in the Database tool's Settings tab, and for the development database the docs are explicit about its reach: "Because DATABASE_URL is scoped to your app, your development database cannot be accessed by other apps, even ones you own, or by external database viewers. Even if leaked, it cannot be used by anyone else to access and modify your database" (Replit docs, 2026).

That is a real security win and a real portability constraint at the same time. It means you cannot point pg_dump, psql, or a GUI client at the database you are building against. The external door is on the other database: "You can connect to your production database from any PostgreSQL-compatible SQL client using the connection string from the production database's Settings tab."

Two practical consequences. First, a full-fidelity dump on Replit is a production operation, so the app has to be published before the escape hatch exists. Second, there is a legacy split worth checking: apps still on the older Neon development database also expose PGHOST, PGUSER, PGPASSWORD, PGDATABASE, and PGPORT, and the docs note these "are not provided for databases hosted on Replit's current infrastructure." If a tutorial written a year ago tells you to grab PGHOST, that advice has expired.

For day-to-day work Replit also offers a My Data tab where you can browse, run SQL, and "export data to a file for external use" (Replit docs, 2026). That covers inspection. It is not the same as a dump.

Bolt.new: the claim path is the whole story

By default, "new projects use Bolt Database" rather than a database in your own account (Bolt help center, 2026). Left there, that is Tier 3. What moves Bolt to Tier 1 is a documented migration: "Claiming your database lets you migrate an existing Bolt database to Supabase," and the stated reason to do it is "if you need external management tools, SQL editing, or advanced monitoring."

Two details decide whether this works for you. It requires Supabase organization ownership: "To claim your database in Supabase, you must be a Supabase org owner. These permissions are controlled through your Supabase account, not through Bolt." And there is a trap next to it. If you already have a Bolt database and you connect a Supabase database instead of claiming, Bolt warns that "connecting a Supabase database will replace the connection, which may cause data loss. You may want to claim instead" (Bolt help center, 2026).

Connect and claim sound like synonyms and are not. Claim carries your existing data across. Connect swaps the wiring and can leave the old rows behind. Bolt's own advice is the right advice: if you know you want Supabase, choose it when you create the project and skip the question entirely.

Lovable: a Supabase foundation you do not hold the account for

Lovable is the clearest case of a distinction that gets flattened in roundups. Lovable Cloud is built on Supabase technology: "The built-in backend utilizes Supabase's open-source foundation, which means you get a production-ready environment from day one" (Lovable docs, 2026). Reasonable people read that as "so my data is in Supabase, and Supabase is portable."

The account is the part that matters, and Lovable is refreshingly direct about it: "There is no one-click migration from the built-in backend (Cloud) to your own Supabase project. If you want to move, you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there."

Read that sequence carefully, because it is a Tier 3 workflow wearing Tier 1 branding: export the data, start a new project, and rebuild the schema by hand. Built on Supabase is a statement about the technology. It is not a statement about whose dashboard the database appears in.

The fix is available and it is a decision you make on day one, not day two hundred: connect your own Supabase project, and you are in Tier 1 from the start. As Lovable's docs put it, "Supabase provides a hosted PostgreSQL database, so your app keeps the full power and scalability of SQL without you managing servers" (Lovable docs, 2026), and that project lives under your account and your billing.

Base44: a managed backend with more structure than it gets credit for

Base44 is a managed platform, and its public docs do not describe a connection string, external SQL access, or self-hosting of the data. That places it in Tier 3, and it is a deliberate design rather than a gap.

It is worth being precise about what is there, because Base44 is routinely undersold. Data is modeled as entities with schemas defined in JSON Schema, including validation rules and field types, which means the shape of your data is written down in a portable, standard format even though the store is not. Every table card carries a More Actions menu with View Data, Export, Schema, Recently Deleted, and Delete All, so per-table export is a first-class dashboard action rather than a support ticket (Base44 docs, 2026). Import accepts CSV, XLSX, and JSON. On Elite and Enterprise plans, data version history "keeps automatic snapshots of each entity's records, so you can review, download, and restore an earlier version."

The honest summary: your rows come out cleanly and your schema is at least described in a standard language, but there is no dump, no external client, and the snapshot safety net sits behind the top plans.

Bubble: PostgreSQL underneath, file export on top

Bubble states that it "uses PostgreSQL, an open source database management system" (Bubble manual, 2026). This is the single most misread fact in the category. The engine being Postgres tells you nothing about your access to it, and Bubble does not publish a connection string or SQL endpoint for your app's data.

What you get is export per data type, in CSV, JSON, or NDJSON, driven from the Data section of the editor. It is asynchronous: "Bubble will send you an email when the export is done, with a link to download the file." And it shares infrastructure with your automations, which is worth planning around: "The data export feature operates on the same scheduler that handles API workflows. As a result, if there is a high volume of scheduled tasks, the export feature may have to wait for its turn in the queue, causing delays."

If your exit plan is "I will export everything the week we migrate," test that assumption on a full-size data type before you rely on it.

v0: the most portable database is the one the builder never owned

v0 is an outlier because it does not answer the question so much as decline it. It has no database product of its own. Instead it connects to services through Vercel Marketplace integrations, where v0 can "query and manage your databases (e.g., Neon, Supabase, Upstash)" (v0 docs, 2026).

That means the database is provisioned under your account with that provider, with your billing relationship and your credentials. Portability is inherited rather than granted. If you use Neon or Supabase, you get that provider's PostgreSQL tooling, including standard dumps, on day one.

The trade is the obvious one, and it is not small: you do the provisioning, you hold the credentials, and you own the operational surface. Builders that hand you a database in one click are genuinely faster to start with. They are slower to leave.

The four questions to ask before you commit data

Run this before the schema gets big enough to hurt:

• Whose account holds the database? Log in to the provider directly, not through the builder. If there is no provider dashboard with your name on it, you are in Tier 3 whatever the marketing says.
• Can you get a connection string, and does it work from your laptop? Do not accept that the variable exists. Actually run a client against it. Replit is the reminder that a DATABASE_URL can be real and still be scoped so external tools cannot use it.
• Run one full export early, and re-import it. This is the only way to find the lossy fields, the queue delays, and the relation rebuilding work while the dataset is small enough to fix by hand.
• Ask what a migration looks like in the vendor's own words. Lovable answers this in one sentence in its docs. Vendors that describe the path plainly are usually the ones that have one.

Verdict, August 2026

If leaving is a real possibility, the deciding move happens when you create the project, not when you try to leave. v0 puts you in Tier 1 by construction. Bolt and Lovable both offer Tier 1, but only if you choose your own Supabase project at the start; retrofitting means a claim on Bolt and a manual schema rebuild on Lovable. Replit gives you genuine PostgreSQL and a genuine external door, but the door is on the production database, so plan your dump around publishing. Base44 and Bubble are honest managed platforms: fast, tidy, file export out, and no dump. That is a fair trade for many projects, so long as you make it knowingly.

None of this makes a builder good or bad. It makes them different products, and portability is a criterion you either priced in on day one or pay for later.

Where this fits

This guide scores one axis. The neighbouring question, whether the application code itself is yours to export and deploy, is scored separately in our AI app builder code ownership comparison; the two answers diverge more often than you would expect, and a builder can be strong on one and weak on the other. For the full picture across nine builders and eight criteria, see the comparison matrix. Data is also only one of five layers that decide what leaving actually costs, and it is rarely the binding one: our AI app builder vendor lock-in comparison scores code, data, identity, runtime and exit terms together, and explains why your weakest layer sets the bill rather than your average.