Vector search, native on Informix.
A first-class vector type, four distance functions usable directly in SQL, and an HNSW index that answers a million-vector query in about seven milliseconds — inside the Informix engine that already holds your operational data. Retrieval-augmented AI, semantic search and recommendations run against the estate you already operate, with no separate vector store to license, secure and keep in sync. Verified row by row against PostgreSQL pgvector.
A first-class vector type
Embeddings are an ordinary vector column alongside the rows they describe. Values are written and read as SQL text — '[0.1, 0.2, 0.3]'::vector — and held internally as a compact binary array of 32-bit floats.
SIMD distance kernels
The distance functions run on AVX2 kernels, eight fused multiply-adds per instruction. On modern CPUs the int8 path folds each dot product into a single vpdpbusd AVX-VNNI instruction, chosen automatically at load with a clean fall-back to AVX2 and scalar.
HNSW index, fully resident
The approximate-nearest-neighbour index is a native access method held resident in shared memory. At one million 1,024-dimension vectors it reaches recall@10 of 1.000 in the default int8 codec, with no cold-cache tail.
pgvector-compatible
The function names and semantics mirror pgvector, and the float32 on-disk layout is byte-compatible. A migration from pgvector is a data copy, not a query rewrite.
Where the vector type sits
How the vector type works
Four moving parts: the type, the distance functions, the HNSW index, and the storage codec that sets the memory ceiling.
The type
A native vector data type stores a flat array of IEEE 754 single-precision floats. The shipping configuration carries up to 3,072 dimensions per vector — matching OpenAI text-embedding-3-large out of the box — with an architectural ceiling of 8,191. The embedding lives in the same table, the same transaction and the same backup as the business data it describes.
The distance functions
Four metrics — cosine_distance, l2_distance, inner_product and l1_distance — are called directly in ORDER BY and WHERE, fused with ordinary predicates on tenant, date, price or permission in a single statement. Similarity search composes with the rest of SQL rather than round-tripping to a separate service.
The HNSW index
The approximate-nearest-neighbour index is a small-world graph built as a native access method and kept resident in shared memory. An explicit predicate — vector_near(embedding, query) or a direct hnsw_knn_ids() call — routes the query through the graph; an exact re-rank on the distance function orders the candidates it returns.
The int8 codec
The default codec quantises each vector with its own per-vector scale, holding one signed byte per dimension plus a four-byte reciprocal. It uses roughly four times less memory than float32 — 2.57 GB resident for a million 1,024-dimension vectors against 7.2 GB — and stays near-lossless, holding recall@10 at 1.000 at that scale. A float32 codec remains available when bit-exact, pgvector-compatible storage is required.
The honest position against pgvector
The comparison below is measured, not asserted. Every figure comes from a harness that runs the same seeded dataset through a Java reference, Informix and PostgreSQL, and reports a number only once all three agree — with both engines on the same host and one equidistant client. Where pgvector is stronger, the table says so.
Where pgvector wins: ergonomics and packaging. It
exposes native operator symbols in ORDER BY, its
optimiser routes the index without an explicit predicate, its
VACUUM reclaims dead index nodes automatically, and it
loads faster by default. Informix needs a function-call form, an
explicit predicate to activate the index, and a manual repack call
for maintenance.
Where Informix wins: the numbers that decide an OpenAI-scale RAG workload. It reaches higher recall at a fraction of the footprint, answers a resident query with no page-fault tail, and is the only engine here that can build an ANN index above 2,000 dimensions — the wall pgvector's HNSW index hits, and the dimension count the current generation of embedding models emits.
Informix vector and PostgreSQL pgvector — measured, one host, one million 1,024-dimension vectors
| PostgreSQL pgvector | Informix vector (ifxtools) | |
|---|---|---|
| Recall at one million vectors | 0.996 recall@10 at 1,024 dimensions. | ✓ 1.000 recall@10 at 1,024 dimensions, in the default int8 codec. |
| Indexed query latency | About 17.6 ms mean; the memory-mapped graph carries a page-fault tail. | ✓ About 7.4 ms; the graph is fully resident, so the mean equals the median and there is no cold-cache tail. |
| Index footprint | Roughly 7.6 GiB on disk, plus the page cache it needs to stay fast. | ✓ 1.11 GiB on disk and 2.57 GB of resident RAM — the smallest of any engine measured. |
| Maximum indexed dimensions | HNSW is hard-capped at 2,000; above that only a brute-force sequential scan is possible. | ✓ HNSW to 8,191; OpenAI text-embedding-3-large at 3,072 dimensions indexes natively, where pgvector cannot. |
| Bulk load | Faster by default, through a pipelined batch load. | ✓ The text protocol is slower per row; the optional binary transfer path reaches about 1,700 rows/s and closes the gap, byte-identical to the text load. |
| Query ergonomics | Native operator symbols, and the optimiser routes the index from an ORDER BY alone. | ✓ Function-call form; an explicit vector_near predicate or an hnsw_knn_ids() call routes the index. |
| Index maintenance | Automatic — VACUUM reclaims dead nodes in the background. | ✓ Explicit — hnsw_index_repack() reclaims tombstoned nodes on demand, scheduled after large bulk deletes. |
| Where it lives | A separate PostgreSQL estate to stand up, secure and operate. | ✓ Inside the Informix engine already in production, under the security model, auditing and backup you already run. |
Where an in-database vector type pays off
Every pattern shares one shape: a similarity search fused with ordinary SQL filters in a single governed query, with no second datastore to keep in sync.
Enterprise RAG and knowledge assistants
Chunk embeddings sit beside the governed rows, so retrieval enforces entitlements in the same statement — a user never retrieves context they are not cleared to read. Sensitive content never leaves the database boundary, and existing access control, encryption and HA/DR cover it unchanged. The fit for finance, healthcare, government, legal and insurance is where grounded, private and permission-aware retrieval is a hard requirement.
Semantic search and recommendations
Shoppers search in natural language and expect results that are relevant and in stock, in region and in budget. Because the catalogue, live inventory and pricing already run in Informix, semantic relevance composes with those filters in one query, and inner_product on pre-normalised embeddings drives the recommendations — no round-trip out to a vector service and back to re-apply the constraints.
Fraud, anomaly and entity resolution
The similarity score is computed in the engine that owns the transactional record: how far a transaction's embedding sits from an account's recent baseline, scored next to the live ledger for sub-second triage. For duplicate and fuzzy-matching entities the vector match pairs with the sibling trigram capability, giving semantic and lexical similarity in one database across banking, telco, insurance and master-data work.
Before you put embeddings in the estate.
Does this run inside Informix, or beside it?
Inside. The vector type, the four distance functions and the HNSW index are native extensions that run in the engine and are addressed in ordinary SQL. The embeddings live in the same table, the same transaction and the same backup as the business data, governed by the same access controls. There is no separate vector service to deploy, secure, patch or keep in sync with the source of truth.
How compatible is it with pgvector?
The function names and their semantics mirror pgvector exactly, and the float32 on-disk layout is byte-compatible with pgvector's vector(n). The same SQL runs on both engines with one substitution: pgvector's operator symbols — <=>, <->, <#>, <+> — become the equivalent function call in Informix, because Informix does not allow custom operator symbols. A migration from pgvector is therefore a data copy, not a query rewrite.
What vector dimensions are supported?
Up to 3,072 dimensions out of the box — matching OpenAI text-embedding-3-large — with an architectural ceiling of 8,191 for an indexed vector. This is the decisive difference from pgvector at production embedding sizes: pgvector's HNSW index is hard-capped at 2,000 dimensions and can only sequential-scan above that, so Informix is the only engine measured here that can build an ANN index over 3,072-dimension embeddings.
Where does pgvector still have the advantage?
In ergonomics and packaging, stated plainly. pgvector exposes native operator symbols in ORDER BY, its optimiser routes the index without an explicit predicate, its VACUUM reclaims dead index nodes automatically, and it loads faster by default. Informix uses a function-call form, needs an explicit predicate to activate the index, and reclaims dead nodes through an explicit repack call. Where Informix pulls ahead is recall, footprint, dimensions above 2,000, and predictable resident latency.
What is the int8 codec, and does it cost accuracy?
It is the default storage codec, quantising each vector with its own per-vector scale — one signed byte per dimension plus a four-byte reciprocal folded back into the distance. It uses roughly four times less memory than float32 and stays near-lossless: recall@10 is 1.000 even at one million 1,024-dimension vectors, and the top result is always exact. A float32 codec is available when bit-exact, pgvector-compatible storage is what you need. The codec is fixed at index build time.
Do we need specific CPU hardware for the fast path?
No. The engine detects the CPU at startup and selects the fastest available kernel — AVX-VNNI, then AVX2, then scalar — from a single portable module built for the x86-64-v3 baseline. On CPUs that expose AVX-VNNI the int8 dot product runs as a single vpdpbusd instruction, and the result is bit-identical to the standard kernel, so recall is unchanged whichever path runs. Which kernel is live is reported at index creation and through hnsw_am_stats().
How do we make a query use the HNSW index?
An explicit predicate routes it. A WHERE vector_near(embedding, query) clause, or a direct hnsw_knn_ids() call — the recommended production path — activates the graph, with an ORDER BY on the distance function doing the exact re-rank of the candidates. An ORDER BY on the distance alone does not route through the index; it falls back to a scan. The candidate-list size ef_search is a per-query knob that needs no rebuild, and the default of 100 holds recall@10 at 1.000 through a million 1,024-dimension vectors.
Which Informix versions does it run on?
Informix 14 and 15, verified against live engines in an automated parity suite on both. The on-disk index format is identical across the two major versions, so an index built on one reloads on the other with no data migration. Informix 15 widens the internal row identifier the index uses for the exact re-rank, and the module handles both widths transparently.