Replit database alternatives: what you are actually running

Replit is one of the fastest ways in existence to get from an idea to a URL that other people can open. I am not going to pretend otherwise, and nothing in this post is an argument to stop building there. The app can stay exactly where it is.

The database is a separate question, and it sneaks up on people because "the Replit database" is not one thing. There are three, they behave differently, and the differences only become visible at the moment you need something from them: a bill you can predict, a connection from outside the Repl, or a second kind of database that Postgres is not.

What the Replit database actually is

Three surfaces wear the same name.

The production database is Neon. That is not a rumor or an inference: Replit's production Postgres runs on Neon and is billed by usage. Practically this is good news, because it means your production database is real Postgres with a real connection string. You can find it in the Database pane under the Settings or connection details tab, paste it into psql, TablePlus, DBeaver, a migration tool, or another host, and it works. Nothing about your data is trapped.

The development database is not Neon anymore. Replit has been moving development databases onto Helium, its own managed Postgres, and development databases are deliberately not reachable from outside the Repl. Even a connection string that leaks is useless to someone on the outside. That is a sensible sandbox decision and not a trap, but it does change the mechanics of moving one: instead of pulling the data out from your laptop, you push it out from the Repl's own shell. It is one command, and the step-by-step version is in the migration guide.

ReplDB is the old one, and it is small on purpose. It is a key-value store you talk to over HTTP, with hard ceilings: 50 MiB per store, 5,000 keys, 1,000-byte keys, and 5 MiB values. Those numbers are fine for saving user preferences or a leaderboard for a game jam. They are not a cache for an app with traffic, and they are not a queue.

Knowing which of the three you have is most of the work. Everything below is about the first two.

Usage billing is the wrong shape for a spiky project

Usage billing means you are not buying a database, you are buying whatever the database did: compute time, storage, data transferred. It is a genuinely good model for two kinds of workload. One is a database that is truly asleep most of the time and costs close to nothing while it sleeps. The other is a business whose revenue moves with the same traffic that moves the meter, so the bill scaling up is a sign the month went well.

Side projects and Agent-built apps are usually neither. Their traffic looks like this: nothing for four days, then you post it somewhere and get a spike for six hours, then nothing again. The revenue is zero throughout. A meter turns every one of those spikes into a small unknown, and the unknown is the actual cost, not the dollars. I have watched people leave a project half-shipped because they were not sure what launching it would do to a bill, which is a genuinely terrible reason for software to not exist.

Flat pricing removes that specific question. On Layerbase Cloud, Free is $0 with no card, Solo is $5/month, and Pro is $15/month, and none of those numbers move because your app had a good day. You know the bill on the first of the month, which is the whole feature.

To be fair about where flat pricing does not win: if your database is genuinely idle forever, a meter that scales to zero is hard to beat on price, because zero is zero. Our answer to that is the free tier, which is also $0, and idle databases hibernate and wake up when something connects. The comparison that matters is not "idle versus idle", it is what happens the week the project is alive.

The good news: it is just Postgres

The thing I want people to internalize about Replit's database is that the escape hatch is already in your hands. Your production connection string is sitting in the Database pane. Postgres is Postgres. Your tables, indexes, constraints, sequences, and rows are standard, and they move with pg_dump like anybody else's.

This is not true of every platform. Plenty of app builders wrap their data in an SDK, and getting it out means writing a script that paginates their API and hopes nothing changes underneath it. Replit did not do that, and it deserves credit for it.

The one exception is the development database, and it is a scoping decision rather than a lock: Helium is sandboxed to the Repl, so the copy runs from inside the Repl instead of from outside it. Same pg_dump, different direction.

The lock-in is in the driver, not the database

Here is the part that actually bites Replit Agent apps, and it is worth understanding even if you never move anything.

A lot of Agent-generated code uses @neondatabase/serverless, the Neon driver that queries over HTTP instead of over a Postgres socket. It is a good driver and there are real reasons to use it, especially from runtimes that cannot hold a TCP connection. But it does not speak the Postgres wire protocol. It sends HTTP requests to a Neon proxy, which means the driver, not the database, decides where your app can point.

Replit's own move to Helium made this visible in public: apps broke, and what broke was the driver, not Postgres. The data was portable the entire time. The client library was not.

The lesson generalizes past Replit. If you want to stay free to move, either use a driver that speaks plain Postgres (pg, postgres.js, anything your ORM ships), or pick a host that answers the protocol your driver already speaks. We ended up doing the second thing: every Layerbase Postgres answers the same HTTP protocol @neondatabase/serverless uses, so a Replit Agent app can point that driver at a Layerbase connection string and keep working, and can also drop to pg over TCP whenever it wants. Two doors, and you own both keys.

When the built-in database is fine

I would rather you not migrate anything today than migrate for the sake of it. Stay where you are if:

• You are still building. Nobody is using this yet and the database has never cost you a real dollar. Ship first.
• The database exists to serve exactly one Repl and will die with it. Prototype scratch data does not need a home of its own.
• One pane of glass matters more to you than the bill. There is real value in the app, the shell, the secrets, and the database all being in one browser tab, and splitting that up costs you something.
• Your included usage covers it and always has. If the meter has never surprised you, it is not a problem you have.

The signals that it is time to move are pretty specific:

• You have started checking the bill. Not paying it, checking it. That is the tax I mean.
• Something outside a Repl needs the same data. A Vercel preview, a cron job on a VPS, a colleague with a SQL client, a local dev machine. This is the most common one by far, and it is where the development database's sandboxing becomes a wall rather than a nicety.
• You need a second kind of database. A cache, a vector store for the AI feature, a search index, a time-series database for metrics. Postgres can fake several of these and then stops being able to. Layerbase Cloud runs 18 engines on one account and one bill, so the second engine is a dropdown rather than a second vendor.
• You want backups and branches you control. A restorable copy you can prove exists, and a throwaway branch of production data to test a migration against.

What moving actually involves

Less than people expect, and specifically it does not involve leaving Replit.

Your app stays deployed on Replit. You create a Postgres on Layerbase, copy the data across, and change one secret: DATABASE_URL. The code does not change unless you want it to. That is the entire shape of it, and it is why this is worth doing on a Tuesday afternoon rather than scheduling as a project.

The guided version lives at layerbase.com/migrate/replit: sign in, paste your Replit Postgres connection string, and it provisions a database and copies your schema and data in one pass, reading once and writing nothing back. If your database is a development (Helium) one, the page gives you the shell one-liner instead, because that is the only direction that works.

If you want the whole thing spelled out, including the driver swap and how to verify your row counts landed, that is Migrating from Replit to Layerbase. If your production database is Neon-backed and you would rather think of it as a Neon move, the Neon migration guide covers the same ground from that angle, including the pooled connection string gotcha.

ReplDB is the one piece that is not fully handled yet. A one-click ReplDB to Valkey importer is coming, so your key-value data gets a real cache instead of a 5,000-key ceiling. Until it lands, the migration page says so rather than quietly implying otherwise.

Short version

Replit is a great place to build an app and the database that comes with it is a genuinely reasonable default. It is also usage-billed on production, sandboxed on development, and capped hard on ReplDB, and those three facts are what eventually send people looking.

The reassuring part is that leaving is cheap because Replit did the honest thing and gave you Postgres. One connection string, one secret, and the app never moves. If you want to run the same database on your laptop while you work, the Layerbase CLI starts real Postgres locally with no Docker, which pairs well with the same argument I made about local Postgres and the one-connection ceiling.