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.
Replies (3)
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. 😊
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.
Yes, as a matter of fact, my first job was about migrating a Delphi + Oracle ERP system where all the business logic was coded as Stored Procedures to PostgreSQL. Things like 3000 line SQL queries and 10,000 like PL/SQL triggers and functions where common. It took us a one year, but it worked and saved the company millions of dollars in licenses alone.
