Replit database empty after deploy: where did my data go?

Symptoms

• The app works fine in the Replit workspace with all your test data, but the live app's database is empty after you publish
• Data you add while continuing to build never shows up on the live site
• It looks like Replit wiped your database at deployment
• The workspace Database pane still shows every row you thought you lost

Why it happens

Replit creates a separate production database at first deployment

Since the post-SaaStr safety changes in July 2025, Replit provisions a production database (hosted on Neon) the first time you deploy. It receives a fresh copy of your schema but none of your development data, so the live app starts with empty tables.

Development data stays in the development database by design

Your dev data lives in the dev database on Replit's infrastructure, and the Agent is deliberately blocked from touching the production database. That block is the guardrail that prevents another SaaStr-style incident, and an empty prod database is its visible side effect.

Migrations carry schema, not rows

At redeploy time, Replit's migration step diffs the dev and prod schemas and applies migration statements to production. Row data is never copied, so anyone who does not know about the split reads the empty production database as data loss.

How to fix it

1. Check which database you are actually looking atThe Database pane in the workspace shows the development database. The deployed app reads the production database. They are different databases with different contents, so identify which one is in front of you before concluding anything is missing.
2. Confirm your dev data is still thereOpen the development database from the workspace. Your rows are still in it; nothing was deleted at publish time. What you saw on the live site was a brand-new production database that started empty.
3. Move seed data to production deliberatelyIf production genuinely needs seed or reference data, export it from the development database and import it into the production database yourself, or build an admin/seed flow in the app. Replit does not copy rows automatically, ever, so this is a manual, intentional step.
4. Redeploy after schema changesWhen you change the schema during development, redeploy so Replit's migration step diffs the dev and prod schemas and applies the migration statements to production. Until you redeploy, the production schema stays where it was.
5. Do not load production data back into devResist the shortcut of copying real production data into the development database the Agent can write to. That recreates exactly the pre-incident risk the separation was built to eliminate.

How to prevent it

• Learn the split once: workspace Database pane is dev, deployed app reads prod, and rows never cross automatically
• Build a repeatable seed script or admin import flow instead of hand-copying data at each deploy
• Redeploy after every schema change so migrations reach production
• Keep real user data only in production, where the Agent cannot touch it

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

Frequently asked questions

Sources

• Replit docs: Production databases
• Replit blog: Introducing a safer way to vibe code with Replit databases
• Replit blog: Production databases and automated migrations
• Replit Builders: OK, but where did my database go?

Related errors