It's actually not really that much of a bandaid, when you think about it.

It's a general purpose extension to a simple tie that provides SQL-like concurrency to a standard hash mechanism.

For what it's worth, the code to convert the app to a half-baked SQL solution is actually written. There is just a fairly high scare factor in actually using it.

Current code uses the ability to lock the entire database as a way of ensuring data integrity (say during financial operations). That needs to still happen, but if we left all the locks in as they were we'd gain no benefit from having SQL.

The solution was to use PostgreSQL's SELECT ... FOR UPDATE in appropriate places, along with SET TRANSACTION SERIALIZABLE to lock rows we are about to (or may be about to) change.

All of these things mean API changes and possibly data integrity issues if not done correctly.

Breaking the API as little as possible is a real issue here.