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…???