Silberengel @Silberengel - 8d
Ever tried migrating one? They're often absolutely gigantic, full of procedures and complex views and classes (tables), and function as de facto interfaces for myriad other applications. And you usually have to migrate in production, or run it in parallel with the new one, for months. And for little gain, other than decreasing your maintenance work by increasing the chances of joining the AWS 7-hour outage.
Also, look at the type of applications still running Oracle. It's like with COBOL: all the stuff that CANNOT GO DOWN, DON'T MOVE IT EVER, EVERYONE'S LITERALLY GONNA DIE. Fun fact: COBOL was my second programming language and Oracle was my first DB. We regularly get requests for maintaining both of those things, and it pays well. 😊
David @mleku - 8d
this is the plague of centralized databases and something that the nostr architecture can fix. most of the solution relates to distributed replication and multi-server fetching strategies, though the tech being used for this is still pretty primitive on most relays.
They often capture and distribute the events during the input/output step, to have multiple instances of the same data set, at different company offices. Their events have unique keys, now. It's all moving toward the Nostr concept, it's true.
