[benoau]

Data gets bundled in CSV or JSON files and inserted during the migration process via seeding. This isn't user data this is reference data and supporting data the application needs prepopulated. You end up with a two-step process, the db builds and then the inserts run.

In local dev you're usually starting from a blank database and sequentially executing the entire history of changes for the database, so it's not prone to breakage unless that sequence changes, or you're updating an already-builty database but you've made manual changes that are not compatible with the scripted changes.

For shared databases Liquibase supports rollbacks which let you undo whatever you just did as long as you have defined that process. Sequelize does too. Basically your changeset or migration script define how to perform the change and how to undo it.

In shared databases there's two risks I've encountered, one is that data in that db that isn't present in local dev will need wrangling before a change can be executed, the other is that tables and columns can be dependencies of views and stored procedures and the like which may be managed separately so you're balancing the defined changeset against external/unknown changes.

[rafaelquicdb]

hmm, that makes sense, thank you!

The reason I'm asking is I'm trying to validate if something I'm building would be useful for dev teams to enhance their productivity.

Not trying to sell anything, just looking for honest feedback if people would pay for this or if I'm wasting time.

https://quicdb.com/

It's basically postgresql ephemeral, isolated, secure, branches, like Neon/Supabase have, but works with any setup.

In any case, thank you for your insights @benoau!