Replit development vs production database: how it works, and how not to lose data
Short answer
- Published Replit apps get a production database that is separate from the development database you and Agent work with. Agent cannot modify the production database.
- On first publish, production gets the schema but none of your test data. Later schema changes are applied when you republish, and Agent asks before applying detected changes.
- The main risks left are yours: destructive migrations, no tested restore, and reference data that only exists in development.
In July 2025, a widely reported incident saw an AI agent delete a user's production database on Replit. Replit responded by shipping, among other changes, automatic separation of development and production databases. That fixed the biggest risk. It did not remove every way to lose data. Here is how the setup works today and the habits that keep your customers' data safe.
How the two databases work
- Development database: the one you use while building. Agent can read and change it, including creating tables and test data.
- Production database: created for your published app. It is separate, and Agent cannot modify it.
- First publish: production gets a fresh copy of the schema, with no data from development.
- Later publishes: if Agent detects schema changes in development, it asks during republishing whether to apply them to production.
See Replit's documentation on development and production databases for the current details.
The risks that remain
1. Destructive schema changes
Renaming a column looks harmless in development, where the data is fake. Applied to production, a rename can be executed as "drop the old column, create a new one", and the data in it is gone. Review every schema change before accepting it for production.
2. Missing reference data
Your app may depend on rows that only exist in development: pricing plans, categories, feature flags, the first admin user. Production starts empty, so the app breaks in confusing ways. Keep a seed script that creates required reference data and run it deliberately.
3. Code and data out of sync
Rolling back code to a checkpoint does not roll back production data. If a release adds a column and writes to it, rolling the code back leaves data the old code doesn't expect. Plan releases so old and new code can both run against the current schema.
4. No tested restore
Know where your backup and restore options are, what point in time you can go back to, and how long it takes. Test a restore once, before you need it.
Five habits for safe production data
- Back up before every schema change you publish.
- Make changes additive. Add the new column, copy the data, switch the code, and remove the old column in a later release.
- Read the migration. Before accepting a production schema change, look for
DROP,RENAMEandALTER … TYPE. - Seed on purpose. Keep a script for reference data, and never copy test users or fake orders to production.
- Protect personal data. Store only what you need, restrict who can query production, and make deletion possible when a customer asks.
Pre-publish database checklist
- Backup taken and restore location known
- Schema diff reviewed, with no drops or renames on tables holding customer data
- Reference data seeded in production
- Old and new code both work with the new schema
- Smoke test after publish: create, read, update, delete one real record
More launch steps are in our production deployment guide. Want a second pair of eyes on your schema and data setup? That's part of every Ship-Ready Review.
FAQ
Does Replit Agent have access to my production database?
No. Replit separates development and production databases, and Agent can only change the development database. This separation was introduced so that production data stays safe while you build.
Why is my production database empty after publishing?
On the first publish, Replit creates the production database with your schema but not the data from development. Seed the reference data your app needs (plans, categories, an admin account) in production deliberately.
Does rolling back a checkpoint restore my database?
Not by default. Rollbacks restore code and context; to include the development database you have to select it in the additional rollback options. Production data is never rolled back by a workspace checkpoint.
How do I avoid losing data during a schema change?
Back up before publishing schema changes, prefer additive changes (add a column, migrate data, then remove the old column in a later release), and never let a migration drop or rename columns holding customer data without a tested restore.