Using a Replit database in production: dev vs prod, backups

Replit gives every app a development database, and when you publish it creates (or uses) a separate production database for your live users. Agent can change the development database but not production; when you publish, structural changes such as new tables and columns are applied to production, while your data stays where it is. That separation protects you, but only if you know which database you are looking at and you have a plan for backups and risky schema changes.

This guide explains how the two databases relate, how to check which setup your app has, what to watch for when the schema changes, and how restores work.

What is the difference between the development and production database?

The development database is where Agent creates tables, adds columns and fills in sample rows while it builds. The production database holds what your customers type in. Treat them as two different places with two different jobs.

One practical detail from Replit's docs: compute billing for a database pauses after five minutes without activity and resumes on the next query, so an idle production database doesn't run up compute charges.

How do I know which database setup my app has?

Replit moved databases to its own infrastructure (called Helium) and upgraded older apps that used Neon. To check yours, open Settings in the Database tool and look at DATABASE_URL:

• If the host contains helium, you're on the current setup, and the production database is created for you on publish (when the development database contains data).
• If it contains neon.tech, it's the legacy setup. There, you turn on Create production database yourself in the publish settings, with an optional switch to copy your current development data into it.

If you copy development data, be selective. Test accounts with weak passwords, half-finished records and sample orders will show up in front of real users.

Apps that were forked or remixed from older projects sometimes shared one database between copies. Replit retired those shared databases in 2026; if your app was affected, its own migration steps are in Replit's documentation.

What happens to my schema when I publish?

When you publish, Replit takes the structural changes made in development (added or removed tables and columns) and applies them to production. Additive changes are usually safe. These are not:

• Removing a column your code still reads. The live app breaks the moment it queries the missing field.
• Renaming a table or column. Schema comparison tools can read a rename as "drop one, create another", and then the data in the old one doesn't follow.
• Changing a data type, such as text to number, when existing rows don't convert cleanly.
• Adding a required field without a default. Existing rows have no value for it.
• Tightening constraints, such as making a field unique when duplicates already exist.

Replit warns that publishing can cause brief downtime, and it recommends a deployment preview to test database changes before users see them.

A safer way to make a risky change

1. Add the new column alongside the old one, with a default value.
2. Publish, and copy existing values into the new column with a one-time update.
3. Change the code to read from the new column, and publish again.
4. Only when nothing reads the old column, remove it in a later publish.

It takes three publishes instead of one, but no step can lose data. If Agent proposes a rename in a single step on a table with real data, stop and ask for this sequence instead.

How do I look at or fix data in production?

Open the Database tool, select the production database, open My Data and switch on Edit. Use this for small corrections, like fixing a typo in a customer's name. For anything bigger, write the change as a SQL statement, test it on the development database first, and keep a copy of what you ran.

Never point the app you're developing at the production database to "test with real data". That is how test runs delete real records.

How do backups and restores work on Replit?

There are two different kinds of "going back", and mixing them up is a common source of panic:

• Checkpoints and rollbacks return your app's code (and development state) to an earlier point. According to Replit's data recovery docs, rolling back does not restore your production database.
• Point-in-time restore returns the production database to a chosen timestamp. You open the database's restore settings, pick the time and confirm. At the time of writing, Replit's docs list 7 days of history on Core and 28 days on Pro and Teams.

So if a bad publish both broke the code and damaged data, you need both: roll back the code to a checkpoint and republish, then restore the database to just before the damage.

If you remove a database by mistake, Replit keeps it soft-deleted for seven days, during which support can help restore it. After that it's gone for good.

Should I keep my own backups as well?

For an app with paying customers, yes. Platform restores cover mistakes inside the retention window; they don't help if you need data from two months ago, if you lose access to the account, or if you decide to move hosting. Replit's databases run PostgreSQL 16, so standard Postgres tools apply. Check the production database's Settings tab for its connection details and whether your setup allows connecting from outside the app.

A simple routine:

1. Export the production database on a schedule (weekly at minimum, daily if data changes a lot).
2. Store the exports somewhere outside Replit, with access limited to the people who need it.
3. Every few months, restore one export into a scratch database and open the app against it. A backup you've never restored is a guess.

Our guide to Supabase backups covers the same habits for teams that later move the database elsewhere, and moving your app off Replit explains how the data travels if you do.

Quick answers

Does Replit Agent change my production data? No. Agent works on the development database. Structural changes reach production when you publish; your production rows aren't overwritten by development rows.

Can I restore my Replit database to yesterday? Yes, with point-in-time restore on the production database, within your plan's retention window. Rolling back a checkpoint alone doesn't do it.

Why is my live app missing the data I see in the Database tool? You're probably looking at the development database. Select the production database in the Database tool.

Is it safe to rename a column in a live Replit app? Not in one step. Add the new column, copy the data, switch the code, then remove the old column later.

Want a second pair of eyes on your data setup?

A wrong schema change is one of the few mistakes that can't be undone with a prompt. If your app has real users, our Replit app rescue includes a review of how data, Secrets and publishing are set up. You can also start with the free health check, read about staging environments for small apps, or get in touch.