My current gig had a similar problem; changing the DB or putting a layer in front of it at a large scale or really er 'mature' codebase is basically a rewrite,

My current gig had a similar problem; changing the DB or putting a layer in front of it at a large scale or really er 'mature' codebase is basically a rewrite, and that's not really the smart way to play it and it's probably not possible anyway. Start from the top instead of the data. Moving various bits of the API to new implementations/microservices and modernize the stack -- new features, make 'em all standalone services and try to deal with your logic in the app instead of in the db. Move /send/giant_dildo_to?uzer=cyberpunk out of the monolith and to a sep service, and eventually you might get to the point where not a huge amount of the legacy code is actually being hit by anything besides your new code. At that point, the cost of redoing the persistence bit is way less than it was when you started. Depending on your app, you might even get away with creating a new DB and using the orig as a kind of 'feeder' which you run on batch -- all options are open right? But obv it depends what you're doing.