If anyone needs help with DB management across dev and production, drop a message below and let’s turn this post into a central area for us to strengthen our database deployment procedures, and ensure no more “Replit just screwed up my database”
Ok, I now see why so many non-techie users are having problems with Replit databases and publishing to production.
Until now I have used Supabase for DB, but have decided to move back in-house and use Replit’s DB instead. So far I am loving that agent is able to tinker directly with the DB, instead of having to issue instructions for me to apply externally in Supabase. I will definitely become a superfan of this.
However, there is a huge chunk missing from the entire process for making changes to the DB schema (the structure of tables and fields, etc). Indeed, the Replit docs admit prod DBs are still in beta.
Even for someone like me who first started doing DB work in my first job in 1989, I am struggling to see how basic operations for deployment are possible. All this should be databases 101 stuff. Yet, unless I am missing something, Replit has got none of it covered.
For example, right now I have a plain text field and existing data in the production DB. I want to change the field to an enum type. Normally I would prepare a deployment script that would modify this field type and change the data. A very delicate process that has to be synced with the code changes.
I can see no way for any of this to be done. All I can see is “publish my app, which pushes the code and makes the schema changes - even if they completely break the data”. in fact, I am pretty sure this WILL break my data.
I must have missed something - anyone got any clues…???
1 Like
As the Replit provided Dev DB is a separate one from the Production DB, any data doesn’t seem to trasnfer and needs to be re-seeded or entered in the Prod DB. This seems ok as then the Prod DB has no test / dummy data in it but also means that changes to the Dev DB no longer reflect the Prod DB and can cause issues. Would be better to provide a Clear test Data function in the Dev DB and link or synchronise the Prod DB to the Dev DB.
I have had what I think is a very similar issue. I am hoping to get information on how Replit provisioning works relative to some of the setting that can be made manually. In my case Dev and Prod fell out of synch. Not sure why, other than I made dev changes that somehow didn’t get picked up fully and pushed consistently. Not sure. But have gotten is stable (I think) and when I go to publish the provisioning tool is trying to “help” me and by doing so it will either double up some tables or potentially recreate some old ones. Here is what I shared with Replit service but havn’t heard anything.
"I have ignoreDatabaseMigrations = true set but the deployment conflict dialog still appeared. If I click Submit, will Replit’s provisioner execute DDL against my production database, or does my setting prevent that?
My .replit file has ignoreDatabaseMigrations = true in the [deployment] section
My deployment run command is bash scripts/start-prod.sh which runs a custom Drizzle migration runner (db-migrate.js) that applies our own migration files from /migrations/
Dev DB has 84 tables, production has 71 — the 13-table difference is intentional and will be handled by our migration files
This is the first deployment since a significant schema update (migrations 0022–0030)
Does ignoreDatabaseMigrations = true prevent ALL provisioner DDL execution, including when I click Submit in the conflict resolution dialog? Or does clicking Submit bypass that setting?
If I click Submit and select “Create new table” for each new table — will Replit execute those CREATE TABLE statements against production, or is this dialog purely informational?
Is there a way to dismiss or skip this conflict dialog entirely when ignoreDatabaseMigrations = true is set, so our own migration runner handles everything?
If both Replit’s provisioner AND our start-prod.sh migration runner attempt to create the same tables, what happens — does one take precedence, or does it cause a conflict error that fails the deployment?
Is there a deployment log from a previous successful deployment I can reference to confirm our migration runner is running in addition to or instead of the provisioner?"