The Rdb Conundrum and Ways to Solve It

With the VMS Software OpenVMS Malmö Bootcamp 2026 imminent, I thought it would be sensible to review the agenda and see what piqued my interest.

A quick read through and my eye was drawn to a topic of great importance: Rdb.

Before getting into the detail, I'd like to share my sorrow at the news of Kevin Duffy's passing. Kevin was the key man for Rdb for a number of years. He was the interface between OpenVMS and Oracle, and the cheerleader for the product. He was involved in every key discussion and always led from the front. He will be sorely missed by those who knew him.

As most of you will know by now, Oracle is not going to migrate Rdb to OpenVMS X86. I can't recall seeing an official press release, but I can imagine how the decision was reached. This will be the first OpenVMS Bootcamp since that announcement, and it is sure to be one of the defining topics of the conference.

The reason this piqued my interest is because it has been on the cards for a number of years. Products were late to market, dependencies were never quite ready, and roadmaps involving OpenVMS were always vague at best. To be honest, this shouldn't come as a surprise to anyone. Rdb was a very small piece of Oracle's business. Probably the only thing that kept it alive for so long was the influence of certain customers - and Kevin's persistence in reminding Oracle management of that fact. But its time was always running out, and so it is. The last platform to support Rdb will be Integrity.

So what is happening at the Bootcamp? There are seven sessions focused on moving from Rdb to an alternative database. That's a significant shift from previous years. Mimer and Sector7 have consistently discussed migration away from Rdb, but it's encouraging to see a broader range of speakers now making the same case openly.

That's not a criticism of Rdb. In its day, it was probably the most robust and reliable database on the market. Unfortunately, post-1994 it never received the investment it deserved, and was largely kept alive by customers who were reluctant to move to Oracle DB.

So where does that leave existing Rdb customers? With seven Rdb-related sessions at the 2026 Bootcamp, and plenty of conversations happening over coffee and the odd beer, there is no shortage of discussion. If you use Rdb and want to stay on OpenVMS, there are three main options to consider:

1. Remain on Alpha or Integrity and don't upgrade to OpenVMS X86.
   This is the path of least resistance, but it comes with real risks around hardware support and the ability to develop or modernise your environment over time.
2. Migrate to OpenVMS X86 and move your database to a separate platform.
   This means hosting an alternative database - possibly Oracle DB on Linux - and using a connector application to link the two systems. It allows you to retain your existing application while moving to a supported architecture. Oracle will likely advocate for this approach with their existing Rdb customers, though the database doesn't have to be Oracle. Any database of choice could work within this model.
3. Migrate to OpenVMS X86 and migrate your database at the same time.
   Options such as Mimer, SharkSQL, or PostgreSQL are worth considering here. This removes the connector layer from the architecture entirely and takes Oracle out of the picture altogether. The complexity is similar to option two, but the long-term footprint is cleaner.

These are the three most obvious paths, but the decision is rarely straightforward. Cloud computing, virtualisation, and clustering requirements all add layers of complexity. Beyond the technical considerations, there are strategic, resource, and budgetary factors to weigh - migrations are rarely cheap.

After speaking with many OpenVMS customers over the years, I understand how significant this decision is. The first Bootcamp since the Oracle announcement, with a range of speakers openly discussing the options, feels like a turning point. What had been a long-standing corridor conversation is now out in the open. Personally, I think that's a healthy development. The OpenVMS community has moved from years of uncertainty to a clear picture of where things stand - and that clarity, however uncomfortable, is something to work with.

What I'd like to see now is for Rdb customers to be able to plan their future environments without the ambiguity that has surrounded Oracle's position for so long. And for OpenVMS engineers to be able to focus on known challenges rather than speculating about what may or may not happen next.

The Newcorp team will be at Malmö and, like many in the room, will be watching these sessions closely. If you're attending and want to talk through your options, get in touch: 01477 500766 or OpenVMS@newcorp.co.uk