Glad you liked the articles, Ken.  How IRIS (and Cache) handles the physical side of global storage is, of course, proprietary, but, as the article referred to by Alexander explains, it's done using a fairly classic b-tree architecture.  For performance, access to the physical database is buffered via memory, the amount of which you can configure. Additionally, IRIS and Cache both have ECP networking which adds an amazing level of additional power and flexibility with Globals able to be transparently abstracted across networked machines - needless to say the technicalities of ECP are a closely-guarded proprietary secret!

As my articles explain, however, you can actually implement the basics of global storage on top of a number of other different databases, with BerkeleyDB being probably the closest example to how IRIS and Cache implement them.

Of course, for the average user, how the concept/abstraction of Global Storage is physically implemented is of less interest than how you can harness and make use of Global Storage to do the kinds of things you want to do.  That, of course, was the focus of my articles, to show just some of the most common ways (and some of the lesser-known and very sophisticated ways) in which you can harness Global Storage.

I've sometimes described Global Storage as a "proto-database" - a very simple but powerful and flexible database engine on which you can model pretty much anything else and on which you can layer all the other stuff you need to create your specific database environment.  As such, it's unique in the database marketplace, and it has always baffled me over the years why it's so little known about and used: it blows away everything else out there.

Anyway, a Happy New Year to all fans of IRIS and Global Storage!


If you're wanting to use IRIS with Node.js, you might want to also look at QEWD.  Rather than using the IRIS Native Node.js APIs, it uses the alternative Open Source mg_dbx interface and its APIs (, and QEWD creates an architecture that allows the synchronous APIs to be used safely (via a queue/dispatch architecture which gives QEWD its name).  With QEWD and the mg-dbx interface, you can run Node.js on either the same machine/system as IRIS, or on separate machines/systems via a networked connection, and you can run QEWD either as a native installation or you can use a pre-built/configured Dockerised version, so it's extremely flexible.

QEWD can be used to develop both Node.js REST services and interactive web applications, the latter connecting users' browsers and your back-end over WebSockets.  QEWD does all the tricky technical work for you, leaving you to just focus on your application or API functionality.

Here's a few ways to get started with QEWD:


Using Dockerised IRIS:

Networked connection between QEWD/Node.js and IRIS:

Although it allows use of IRIS via its standard Object and SQL architecture, and APIs QEWD can also abstract the IRIS database as persistent JavaScript Objects/JSON, which allows you to access and use an IRIS database in a completely unique and powerful way that makes it a natural fit with JavaScript.  To explore this aspect of QEWD with IRIS, check out:

These repositories and the documentation/examples/tutorials they contain should get you started


Calling any interested Python developers: It would be interesting for someone to take a look at what I've done in JavaScript/Node.js to implement what I refer to as persistent JSON objects, essentially creating JavaScript objects/JSON that resides on disk rather than memory and which can also be manipulated, traversed and modified in-situ rather than being shuttled between disk and memory.  It's a concept I've referred to as QEWD-JSdb.  Given the native support for JSON that now exists in Python, it strikes me that the equivalent ought to be possible using the new embedded Python in IRIS.  I'm not a Python developer so I'm not the person to implement it, but all the logic for implementing this concept is available in my JavaScript repositories and my assumption is that it should be a matter of recasting the logic in Python.  The really cool part is the multi-model stuff you can then derive from it such as the persistent DOM against which a standard XPath library can then be applied for searches.  For information on what I'm referring to, see:

and a more broad discussion of the underlying concepts:

If anyone is interested in such a project, all I ask is for the appropriate attribution for the original concept.

Open Exchange applications:
Rob has not followed anybody yet.
Global Masters badges:
Rob has no Global Masters badges yet.