https://en.wikipedia.org/wiki/MultiValue https://en.wikipedia.org/wiki/Pick_operating_system
To be fair, I do see some elegance in how they work, but just the trade-offs today aren't the same, so IMO there isn't a good reason to use them when we have graph databases, the modern NoSQL solutions and SQL for that matter.
Essentially, a current document database does more than these solutions can and more reliably.
This is also why, I didn't see NoSQL solutions, like Mongo et al, as something so revolutionary when they came out, to me they are just a modern twist on things we have had for decades.
They have discussed of doing away with it for years (decades?) and it has never happened.
The biggest argument against migrating is "performance" (that a RDBMS or even Mongo will be slower).
We replaced their solution with Postgres, proper caching and clear separation of concerns/layers and they went from queries taking 3-4 second average (some being 30-40 second normally) to being done in 500ms-1s average. Another thing we fixed, some of their data had to be batch processed overnight everyday for like pricing adjustments on the UniVerse system, because concurrency was a major problem for them. After our changes they did real-time pricing adjustments along with a bunch of other similar things. We built them a proper OLTP data solution with a data warehouse with cubes for detailed analytics & reports.
I don't envy anyone having to still work in one of these systems, so many times simple things you could do in a modern system in short durations will turn into a nightmare and a huge drawn out project in Pick/U2. I definitely don't agree with the performance argument, I fought that one for years with different clients and vendors who felt U2 was so fast, and with a properly designed RDBMS I always could beat their performance, especially when concurrency was a key factor. Locking on U2 systems is a complete cluster most of the time for high concurrency systems.
I am no expert and very young in average for people at my company (Junior Engineer), so I've never had a chance to take part in this kind of "big" decisions, but I've always suspected the way Pick/U2 works is the reason we have all kinds of weird limits across the board (as you pointed out, a big one is concurrent [write] access to stuff as U2 does not have transactions/ACID/MVCC). I'm sure paying for U2 also costs a pretty penny.
The company does know that nobody wants to work with U2. If you apply for a job here, they will barely mention it and will train you from scratch instead as it is extremely rare for someone to know this.
Thankfully I don't usually have to work directly with it and instead use SQL/Java, but it never escapes me because this U2 database is the source of truth for a lot of stuff.
How big were the systems you have migrated? How long did it take to "replace their solution"? I feel it must be soul-crushing to rewrite this kind of system entirely, especially testing it.
