Why your Replit fix never reaches your live app's database

You asked the Agent to fix a bug, tested it right there in the workspace, and it worked. You published the app. The live site still has the bug, or a table that had data in the editor is empty on the real site. Nothing crashed and no error told you why: you were looking at two different databases the whole time, and only one of them is what your visitors actually hit.

If you searched “replit data disappeared after publishing,” “replit fix works in editor not live,” or “replit database empty after deploy,” this is almost always the same mechanism.

Why this happens

Every Replit app with a database gets two of them: a development database, tied to your workspace, and a separate production database, tied to your published app. This split is deliberate, not a bug: Replit’s own docs describe it as a safety boundary, put in place after agent work was able to damage production data directly. The Agent can add, remove, or reshape tables in development freely. It cannot touch production at all.

The two only reconcile at one specific moment: publishing. Per Replit’s documentation, schema changes made in development, meaning new or altered tables and columns, get applied to production automatically when you publish. Rows of data do not travel the same way. Development and production hold entirely separate data, and nothing you typed or generated while testing in the workspace was ever written to the live database, and nothing a real user submits on the live app shows up back in your workspace either.

So two distinct symptoms come out of the same root cause:

A fix you verified in the workspace is still broken live, because publishing didn’t complete, or you tested the fix but never actually republished afterward.
Data looks like it vanished after publishing, because a fresh production database doesn’t inherit development’s rows. It never had them to lose.

How to tell if this is your problem

Open the Database pane and look for two views, not one. If your app shows separate development and production databases, this mechanism applies to you directly.
Check whether you republished after the fix, specifically. Saving a file or testing in the workspace preview is not the same action as publishing, and only publishing pushes a schema change toward production.
Match the shape of what’s missing to the right explanation. A column or table missing in production points at an incomplete or skipped publish. Specific rows missing, while the schema itself matches, is normal: that data lived only in development and no publish step was ever going to move it.

The fix

For a schema fix that isn’t showing up live: republish the app. That’s the step that copies development’s table and column structure over to production. If nothing changes after a republish, check your publish settings for older, Neon-backed databases specifically. Some of those require enabling production database creation explicitly rather than getting it by default.

For data you need on the live app: don’t wait on a publish to carry it over, because it won’t. If you need a specific row in production (a seed record, a config value, a test account worth keeping), write it directly against the production database, or run a one-off script targeted at production. Treat “add it in development” and “add it to production” as two separate actions every time.

If data is missing on the live app and you’re sure it should be there: don’t let the Agent recreate empty tables to “fix” it before you’ve confirmed which database actually holds what you’re looking for. Replit’s production databases support point-in-time recovery within a backup window, and even a deleted database can typically be restored for several days after. Recovering real data beats regenerating a schema and losing it for good.

How to avoid this next time

Treat “it works in the workspace” and “it works live” as two separate claims that both need checking, not one claim you’ve already confirmed twice.
Republish immediately after any Agent fix that touches your data model, instead of batching several changes together, so you’re never guessing which of three unpublished edits caused a live gap.
Before debugging application code on a “the data is wrong” report, confirm which database you’re actually looking at. A large share of “my fix didn’t work” reports are really “I checked the wrong database,” and no amount of code changes fixes that one.