Mapepire, a type of pit viper native to South America, is IBM’s new interface layer for IBM-i. Mapepire boasts a logo that’s arguably the best creation from Big Blue since the original IBM emblem. As for how to say it, IBM-i Mapepire GitHub says Mapepire is pronounced ‘mapəpɪə’ or ‘MAH-pup-ee’ which seems nonsense to me! I’ve been pronouncing this as Mape (like Vape) Pire (like Fire) in my head while I am writing this. Let’s see if I can reprogram the neural pathways to think “Mahpooopeeee” or perhaps we should just call it “that fast mapey interface layer”

If you are an IBM i developer who works with RPG, CL, or SQLRPGLE programs, you will want to understand this new tool. It makes connecting modern applications to your Db2 for i database much easier and faster than the old ways.

So, what exactly is Mapepire?

Mapepire is a modern, open source database client for Db2 for i. IBM released it in late August 2024 as a Technology Preview. It was built to solve the problems that many of us have had for years with traditional ODBC and JDBC drivers.

Instead of running heavy client drivers on your application side, Mapepire uses a server component that sits on (or near) your IBM i. Your applications talk to this server using secure WebSockets over a single port. All the heavy lifting like CCSID handling, password management, and data conversion happens on the server. This keeps your client code light and simple.

Why did IBM create Mapepire?

The old drivers (JDBC/ODBC) carry a lot of complexity. They need to handle encodings, support many platforms, and often require native dependencies. This makes them big, slow to update, and tricky to use in cloud and container environments.

Mapepire changes that. The core design principles are:

• Consistent SDK across different programming languages
• Very few dependencies
• No native drivers required on the client side
• Always encrypted communication
• Works through one single port
• Easy to run in lightweight containers and cloud services

This makes it perfect for modern development where your code might be running in Node.js, Python, Java, or even inside tools like IBM WatsonX.ai.

How does it compare to what we already have?

Take a look at this clear visual comparison of the traditional JDBC/ODBC approach versus the new Mapepire client:

As you can see, Mapepire comes out ahead in almost every practical area that matters for modern development teams.

Why should an IBM i programmer care?

Even if you mainly write RPG and SQLRPGLE, Mapepire is still important. It gives you a clean, secure way to let external applications talk to your IBM i data. This is especially useful when you need to:

• Build web or mobile front ends
• Create APIs that other systems can call
• Integrate with cloud services
• Support development teams using different languages
• Move toward more modern architectures while keeping your core systems safe

The server side respects all your normal IBM i security. User profiles, authorities, and exit programs still work as you expect.

Getting started with Mapepire

Mapepire is open source and available on GitHub. You install the server component on your IBM i and then use the client SDK in your chosen language. Clients are already available for Node.js, Python, and Java, with more coming.

I will cover the full installation steps, how to configure the server, and writing your first connections in future posts (a free online course is actively being written here). It pairs very nicely with the IBM i MCP Server we talked about on the IBM BOB course, since Mapepire powers much of that technology under the hood.

Final thoughts

Mapepire is not here to replace your RPG or CL programs. It is here to make it easier for the rest of the world to talk safely and quickly to your trusted DB2 for i data. Talk to your trusted RPG programs, which interact with this DB2 data. This is another smart step in keeping IBM i relevant in the modern development world.

If you are already comfortable with SQL on IBM i, you will feel right at home once you get the basics set up.

The headline story is this: MAPPIRE wins on-box, every time. When your RPG or CL program is running on the IBM-i, there is no faster or tighter path to Db2 for i than the native driver. No JVM tax, no DSN configuration headaches, no network hop.

Where JDBC and ODBC earn their keep is off-box:

JDBC is probably going to stay as your go-to when Java apps need to reach up and talk to your Db2 data. The JTOpen / jt400.jar driver is open source and battle-hardened. The trade-off is the JVM startup cost and the fact that you lose any sense of native IBM-i object awareness.

ODBC is the classic Windows-world bridge, perfect for Power BI dashboards, Excel workbooks, Python analytics scripts, or .NET apps using IBM iAccess Client Solutions. The licensing cost and the need to manage ODBC Data Source Names (DSNs) on every client machine are the usual pain points.

The modernization sweet spot in most shops ends up being a hybrid: MAPPIRE for everything running natively on the box (SQLRPGLE, service programs, CLLE wrappers), JDBC for Java-based integration middleware, and ODBC only where a legacy PC-side tool demands it.

That’s my favorourite way – use the right tool for the job, not the one that has always been used, just because its already installed.

I have a fun weekend ahead… playing with Mapepire and recording some videos of installation, config and programming examples. Is Mapepire Server installation difficult? How can I write code that interacts with Mapepire? Security best practices? Or how to use it with existing SQLRPGLE applications? Why do I keep typing Maprepire rather than Mapepire?