The engineering behind every claim on this site.
Ten papers, written for architects and DBAs rather than for procurement: how each extension is built, what it measures, where its limits are, and how it compares to the PostgreSQL equivalent it is judged against. They are the working documents of the engineering team, published unedited for a technical audience.
Written to be checked
Every benchmark states its hardware, its dataset and its method. Where a result is worse than the PostgreSQL equivalent, the paper says so and explains why.
Implementation, not overview
Data structures, index internals, memory behaviour, failure modes and the SQL that exercises them. The detail an architect needs to approve a component.
Limits stated plainly
Each paper carries a section on what its subject does not do. A boundary declared in writing is worth more than a capability claimed without one.
Informix 4GL
Two backends for the same language, and the case for each. The compiler paper also covers how an estate is surveyed and asked questions before either is chosen.
Informix 4GL to Java
A migration compiler that reads .4gl and .per sources, resolves their types against the live catalogue, and emits Java a developer is expected to read, review and be able to take over.
Informix 4GL on GraalVM
The second backend, which does not translate the program at all: it runs the 4GL as itself on GraalVM, specialised by partial evaluation and compiled to machine code by the same optimising compiler the JVM uses.
Diagnostics
How the estate is read without being disturbed — one paper on diagnosing it, one on watching it.
Informix Diagnostic Agent
The longest paper here. An automated monitoring and root-cause-diagnosis platform for multi-terabyte, high-concurrency, replicated estates on Linux and AIX: the collection model, the probe catalogue, the reasoning layer, the MCP surface, and an appendix of console captures from a real triage session.
Informix SQL Wire-Tap
Reading the SQLI protocol off the wire to reconstruct every statement, its client-observed timing and its errors, without enabling the engine's SQL trace: why the engine cannot measure its own SQL on a busy machine, how the decoder stays synchronised on a protocol it does not control, and what it declines to count.
Capabilities
The six native extensions, each verified against the PostgreSQL capability it is measured against. The two change-data-capture connectors close the list.
Informix Vector Type
A native vector column with AVX2 SIMD-accelerated distance functions, SQL arithmetic on vectors, and a built-in HNSW approximate-nearest-neighbour index — with a head-to-head comparison against PostgreSQL pgvector.
Informix Trigram
Typo-tolerant, accent-insensitive and phonetic string matching inside the SQL engine, plus a trigram inverted index implemented as a Virtual Index Interface access method.
Informix Graph DataBlade
C routines that build an in-memory compressed-sparse-row snapshot of an edge table and answer reachability, where-used and weighted shortest-path queries in a single visit-once traversal.
Informix Extended-Types DataBlade
Ten PostgreSQL-compatible types implemented as opaque user-defined types: the zone-aware timestamptz, the range and multirange family, uuid, citext and the network types.
Informix Kafka CDC Connector
A pure-Java external service that captures committed row changes from the logical log and publishes a Debezium-style JSON envelope per change, with nothing running inside the engine.
Informix Redis DataBlade
Two integration planes: routines that call Redis directly from SQL, SPL and triggers, and a change-data-capture agent that streams committed row changes onto Redis as JSON.
How to read these
Start with the paper for the capability you are evaluating. Each opens with the problem in the terms an Informix estate actually meets it — a query that cannot be expressed, a store that has to be kept in sync, a diagnosis that arrives after the evidence has gone — and only then describes the mechanism.
The benchmarks are the part worth reading adversarially. Each states the hardware, the dataset, the row counts and the method, so the numbers can be reproduced or disputed. Where the PostgreSQL equivalent wins, the paper records it and explains the cause rather than omitting the row.
If a paper leaves a question open, that is what the diagnostic run is for: it reads your estate rather than a benchmark, and the report it produces is the same shape as the evidence in these documents.