I can sympathize. We have a Twisted database abstraction layer that was built in house. You call http endpoints that perform database operations. It has routing

I can sympathize. We have a Twisted database abstraction layer that was built in house. You call http endpoints that perform database operations. It has routing logic so applications only need to call someEndpoint.json and not worry if we've sharded the backend recently, scaled read replicas, migrated a write master, etc. It has caching, query piggy-backing, connection pooling, and other bells and whistles. While we have been able to scale it out for volume of requests, it did not scale well for multiple teams and multiple services. It became a single point of failure whereby the access patterns of one team to their own databases could affect other teams abilities to access their own databases. We've since moved to a new model whereby team's own their datastores and access methods, speeding up development and reducing negative impact teams can have on each other's data layer. Legacy access continues to be migrated off endpoint by endpoint, database by database. I look forward to the day of never having to look at Twisted code ever again. The framework is aptly named. If you are looking for a similar solution for MySQL, I currently recommend ProxySQL. It allows for a topography whereby teams can control their own proxy layer and still have most of the benefits outlined above.