The capabilities of a modern data platform, native on Informix.
Four native extensions that run inside the engine — vector search, fuzzy and phonetic search, graph and extended types — and two change data capture connectors that stream committed changes out of it, to Kafka or to Redis. Together they bring the estate to parity with what a PostgreSQL shop expects, each verified against its PostgreSQL equivalent by exhaustive per-row benchmark on Informix 14 and 15.
Native, not bolted on
Written against the Informix extension mechanism — types, functions and index access methods that run inside the engine, addressed in ordinary SQL.
PostgreSQL parity, proven
Every capability is benchmarked three-way against the PostgreSQL equivalent, row by row, so the behaviour you rely on is the behaviour you get.
Informix 14 and 15
Verified on current Informix releases, against live Dockerised engines, in an automated suite that runs on every change.
The suite
Most are native DataBlades — extensions that run inside the engine, addressed in ordinary SQL. Two use change data capture, streaming committed changes out of the engine to Apache Kafka or to Redis. Each capability stands alone; adopt the ones the estate needs.
Vector search
A native DataBlade. A vector type compatible with the PostgreSQL pgvector model: variable-length float embeddings up to several thousand dimensions, with cosine, L2, inner-product and L1 distance functions usable directly in the query. An approximate-nearest-neighbour index built as a native access method makes retrieval fast at scale. The result is retrieval-augmented AI running against the operational data already held in Informix, with no export to a separate vector store.
Fuzzy and phonetic search
A native DataBlade. Trigram similarity and word similarity, edit-distance functions and phonetic matching, over ordinary character columns. The same function names and behaviour as the PostgreSQL trigram and fuzzy-string extensions, plus a trigram index built as a native access method. Search that tolerates typos, spelling variants and near matches, without standing up and syncing a separate search cluster.
Graph queries
A native DataBlade. Graph traversal over relational data, matching the model the PostgreSQL ecosystem offers through its graph extension. Relationship-shaped questions — paths, neighbourhoods, reachability — answered on the estate that already holds the relationships, rather than exported to a separate graph database.
Extended types
A native DataBlade. Extended data types and their functions, used from ordinary SQL, that close the distance between what the engine ships and what a modern application expects of its store — so more of the application's data needs are met inside the estate you already operate.
Kafka change data capture
Change data capture. A log-based connector that reads committed row changes from the Informix logical log and publishes one message per change to Apache Kafka, keyed by primary key, in a change-envelope format. It runs entirely as an external process, outside the engine, and checkpoints its log position so a restart resumes where it left off. Integration, replication and analytics pipelines fed from Informix without modifying the application.
Redis cache
Change data capture. Committed row changes streamed from Informix to Redis to keep a cache or stream in step with the engine as the system of record — the same capture model as the Kafka connector, a different destination. A synchronous in-engine call path is available alongside it.
Diagnostics
The read-and-optimise pair: an agentless diagnostic that triages the engine and host, and a passive wire-tap that finds the costliest statements on the wire. Read-only, production-safe, and the recommended first step before any of the above.
Why native extensions, not a second system
The usual answer to a missing capability is another system: a vector store beside the database, a search cluster beside that, a graph engine beside that. Each one is another copy of the data to keep in sync, another failure mode, another operational surface to staff.
ifxtools adds the capability to the engine instead. The vector index, the fuzzy-search functions and the graph traversal run inside Informix, addressed in the same SQL, governed by the same access controls, backed up in the same operation. Change data capture is the one deliberate exception — it runs outside the engine by design, so streaming load never competes with transactional work.
Before you evaluate the suite.
Do these run inside Informix, or beside it?
The vector type and index, the fuzzy and phonetic functions, and the graph traversal are native extensions that run inside the engine and are used from ordinary SQL. Change data capture is the deliberate exception: it runs as an external process reading the logical log, so streaming never competes with transactional work and no capture code sits inside the engine.
How do you know the behaviour matches PostgreSQL?
Each capability is benchmarked against its PostgreSQL equivalent by exhaustive per-row comparison in an automated test suite, run against live Informix 14 and 15 engines. Parity is verified, not asserted.
Which Informix versions are supported?
The suite is verified on Informix 14 and 15. The diagnostics additionally read older engines.
Do we have to adopt all of it?
No. Each capability stands alone. Most estates start with the diagnostic run, then add the one or two capabilities the business is actually asking for.
Does adopting these commit us to a migration later?
No. These capabilities exist to make the estate more useful in place. A forward path onto a modern application runtime is available if and when the application tier becomes the constraint, and it preserves the schema and stored logic. It is a separate decision, on your timeline.