We run Informix in production. That is why the tools can be trusted.

What this means for the business

Most Informix estates arrive at the same decision point. The engine is doing its job, the applications above it carry decades of business logic, and the standing advice from the market is to replace all of it. That advice carries a price that is rarely stated plainly: a replacement programme commits budget and senior attention for years, its costs land well before any of its benefits do, and the operation it is replacing still has to run throughout.

The alternative is narrower, cheaper to test and reversible. The capability the business is actually asking for — AI retrieval, search that tolerates human error, streaming integration, analytics — is added to the engine in place. Nothing above the database is rewritten to get it. If the application tier is genuinely what limits the business, there is a forward path for that too, taken on your timetable rather than as the price of the first conversation.

The entry point is deliberately small. A read-only diagnostic run goes over a single connection as an unprivileged database user, with no software installed on the host, and produces a written picture of the estate as it runs today. It commits the business to nothing that follows it.

Where the tools come from

ifxtools did not begin as a product. It began as internal engineering inside Deister Software, a Barcelona company that has built and operated large ERP systems for enterprises in Spain and Latin America since the 1990s — systems that have run on IBM Informix from the beginning, and still do.

Some years ago, Deister moved its R&D and technology development into a unit of its own: Airtool Technologies, the group's technology hub, staffed by a new generation of software engineers. ifxtools is a joint effort of the two — the tools are engineered at Airtool and proven against the production estates Deister operates, under the supervision of the senior Informix architects who have run them since the 1990s.

Every component in the suite started as something a production estate needed. The wire-tap exists because a live SQL problem had to be diagnosed without touching the application. The extended types exist because an ERP module needed capability the engine does not ship. Change data capture exists because an integration had a date on it. Each was written for our own operations, run against our own customers' workloads, and kept in service for years before it was offered to anyone else.

Informix is not the only engine in production here. The practice also runs PostgreSQL — including Aurora on AWS — and the team carries extensive working knowledge of both, with Vertica and ClickHouse alongside for high-performance data analytics. That breadth shows in the suite itself: several of its capabilities began as ideas proven in the PostgreSQL ecosystem — vector retrieval and trigram search among them — re-engineered as native Informix extensions so the estate gains the capability without leaving the engine. The tools are built by people who operate the alternatives daily, which is what keeps the comparisons on this site honest.

That is the distinction worth stating plainly. A tools vendor validates its work against benchmarks. We validate ours against a production ERP that our customers' businesses depend on, where the cost of being wrong is somebody's operating day. The technical papers published on this site came afterwards, to make the claims checkable by people who have no reason to take our word for them.

The engineering team

ifxtools is built by a deliberately structured team. A new generation of engineers at Airtool Technologies writes the extensions, authors the papers and takes the diagnostic calls — trained on Informix alongside PostgreSQL, Vertica and the modern data stack. Senior Informix architects from Deister supervise the work: engineers who have run Informix in production since the 1990s, fluent in C, Java, language and compiler engineering and database architecture, and who review every design before it ships.

That structure is a deliberate answer to the question every Informix estate eventually faces. The engine is not the succession risk — it is documented, supported and running. The people are: most estates depend on developers approaching the end of their careers, with no one trained behind them. For a CIO, engaging this practice converts an internal staffing exposure into a contracted one — the depth the estate depends on stops being a function of who is still on the payroll in five years. It is a problem we solved for ourselves first, by training the next generation under the architects who hold the depth, which is why we can offer to solve it for an estate we did not build.

The seniority shows in the work. Translating Informix 4GL to Java, or running it on GraalVM, is compiler engineering — parsing a language, preserving its semantics exactly, and proving the output behaves as the original did. It is not a conversion script, and it is architected by people who build compilers. The same cross-engine depth is why the capabilities on this site are framed against their PostgreSQL equivalents: that comparison is only meaningful when the people making it operate both engines seriously. This team does.

Why we built this

We work with Informix estates every day, and we kept meeting the same gap: the engine was doing its job well, but the business wanted the capabilities a modern data platform is expected to have — vector search for AI retrieval, streaming for integration, fuzzy search, graph — and the market's only answer was to leave. That answer is usually wrong, and always expensive.

So the site offers three strands of our own engineering, and each exists because our own work required it:

• Extensions & streaming. These are capabilities we use or require in an ordinary working day — vector retrieval, fuzzy search, streaming integration, extended types. We built them as native Informix extensions for our own estates, verified them against the PostgreSQL equivalents, and ran them in service long before offering them to anyone else.
• Diagnostics. We operate large production databases every day, and a problem on a live estate has to be diagnosed quickly, precisely and without touching the application. The tooling is the accumulation of that work — hundreds of hours of detailed analysis and problem review across many years — refined each time a live incident demanded a better question, until the questions we always ask became the tools that ask them. The diagnostic run an evaluation starts with is the one we run for ourselves.
• Informix 4GL. Our own application stack has run on Java since 2000, and along the way we moved our development from Informix 4GL to a language of our own — built with 4GL as its base, interpreted on Java. When GraalVM emerged, we moved that language to Truffle, the framework modern language runtimes are built on. The parsers, the type resolution and the runtime semantics those moves require have been part of our development stack ever since. Informix 4GL to Java, and Informix 4GL on GraalVM, are that experience turned outward: not a migration tool assembled for a campaign, but a path we have already taken ourselves, engineered for the 4GL this market still writes.

That is what ifxtools is: engineering we depend on ourselves, offered to the enterprises that still run Informix and deserve better than being told to abandon it.

What we are working toward: an engineering partner, not a dependency

The goal of this practice is not a licence relationship. It is to be the engineering partner an enterprise technical team calls on when the problem is deep — the estate, the engine, the language, the migration — and to leave that team stronger and more capable after every engagement, not more dependent on us.

The commercial model follows from that, and it goes as far as an organisation wants it to. Nothing we deliver requires a licence from us to keep running. And for organisations that have concluded — after two decades of watching platform licence terms be set at renewal rather than at purchase — that the toolchain of a critical system must be under their own control, the 4GL compiler and the GraalVM execution engine are available under source code licences, with maintenance and support agreements that stand behind the customer's engineering team. An enterprise that takes that path holds the codebase and the engine that runs it, maintained by its own people with us behind them. In an area this critical, self-sufficiency is a position we help our customers reach, not one we protect them from.

What we publish

The work is documented in ten technical papers — implementation detail, method and stated limits, one per component, written for architects and DBAs rather than for procurement. They are collected in the papers library, and each is linked from the page of the capability it describes.

They are published for a practical reason. An evaluation of this kind usually has to survive a technical review before it reaches a budget decision, and asking an architecture team to accept a vendor's summary is the point where most of these conversations stall. The papers give that team the implementation detail, the method and the limits we found, so the diligence can be done properly rather than deferred.

A note on trademarks

IBM, Informix and DataBlade are trademarks of International Business Machines Corporation. The ifxtools suite is built by an independent engineering practice that is not affiliated with, endorsed by, or sponsored by IBM. References to Informix describe compatibility and interoperability only.