A vector index that lives in the database, not beside it.
Two ways to put approximate nearest-neighbour search into a relational engine give very different guarantees. One builds the index as a native access method, inside the same table, the same transaction and the same backup as the row it describes. The other copies vectors out to a second, file-based store and reconciles the two by running a batch procedure. This page lays out the difference for architects who have to sign off on which one carries production data — with every claim about the alternative sourced to its own vendor's documentation.
One system, one backup
The index is a BLOB in an ordinary Informix table. onbar and ontape capture it with everything else, with nothing to configure.
Same transaction, always
A write to the base table and a write to the index commit together. There is no window where one has moved and the other has not.
No second store to reconcile
There is nothing running beside Informix to license, patch, secure or keep available. The engine you already operate is the whole system.
Every claim, sourced
Every statement below about the alternative architecture links to that vendor's own public documentation, not to our summary of it.
Two architectures for the same problem
Two architectures, not two opinions
There are two structurally different ways to add vector search to a relational engine, and the difference is not cosmetic — it decides what a DBA can promise about the data.
Native access method. The index is built as a first-class index
type on the table, the way a B-tree or an R-tree is. It lives in the engine's own
storage, is written inside the same transaction as the row it indexes, and is
captured by the engine's own backup and replication because, structurally, it is
just another table. This is how PostgreSQL's pgvector implements HNSW,
and how Informix's own HNSW access method — detailed
on the Vector search page — implements it here.
Bridged store. The searchable index is a separate product,
in its own storage format, reachable only by copying data into it. Consistency
between the two is not enforced by the database — it is a property of how
recently, and how completely, the copy procedure was last run. This is the
shape HCL Informix VectorBlade takes: a native lvector_embedding
column holds the vector in an ordinary, logged, backed-up Informix row — that
part is native — but the searchable ANN index is a LanceDB-format table,
held outside Informix's managed storage, kept current by a bulk-copy procedure
that has to be run by hand.
What HCL's own documentation says
Not our characterisation — quotations from HCL's published VectorBlade documentation, each linked to its source page.
Where the searchable index actually lives
HCL's introduction to the blade states that for indexing and search, vectors are “copied, using one of several UDRs provided with the blade, to special file system files outside of Informix chunks.” The archiving page names the format directly: “Your lance tables and indexes are stored outside of Informix-managed chunks, in a directory specified by the IFX_LVECTOR_URI configuration parameter.” Source: Archiving lance tables and indexes, help.hcl-software.com.
How the two stores are kept in sync
The lvector_bulk_sync(ifx_table, lvector_table, id_column, lvector_column) procedure is the documented mechanism, described for use “after initial load or after recreating a backing LanceDB table.” It is one-way — Informix into the LanceDB-format table — and it is invoked, not triggered: nothing in the documented procedure fires it automatically on insert, update or delete. Source: lvector_bulk_sync, help.hcl-software.com.
What happens to the logical log
HCL's own archiving guidance is explicit: “Modifications to lance tables are not recorded in the Informix logical logs. Therefore these modifications cannot be logically recovered or replicated using IDS.” That single sentence rules out HDR, RSS and any log-based recovery for the index — the mechanisms an Informix architect already relies on for the rest of the database do not reach this part of it. Source: Archiving lance tables and indexes, help.hcl-software.com.
What a standard backup actually captures
Because the lance store sits outside Informix-managed chunks, onbar and ontape do not capture it. HCL's documented recommendation is to treat the Informix table as the real source of truth and, after any restore, either “separately restore the contents of IFX_LVECTOR_URI or recreate your lance tables using your Informix tables as the source of truth” via lvector_bulk_sync. In other words: plan for the vector index to be rebuilt from scratch on every disaster-recovery drill. Source: Archiving lance tables and indexes, help.hcl-software.com.
What new rows do until the next sync
HCL's documentation for index behaviour states that vectors inserted after the index is built are still searchable — but only because “the search will automatically use the index and then pivot to a brute-force search on the unindexed data.” Every row written since the last lvector_bulk_sync is scanned in full on every query, silently, until someone reruns the sync. Source: Indexing your vectors, help.hcl-software.com.
What LanceDB itself is built to be
LanceDB describes its own product as “the Multimodal Lakehouse for AI” — versioned, branchable datasets for model training and experimentation, where “every write is automatically versioned” and a table can be rolled back or branched for an experiment. Its own site makes no ACID claim and does not present it as a transactional store. It is a well-built tool for what it is designed for — an ML dataset format — which is a different job from being the live index behind an OLTP row. Source: lancedb.com.
What HCL ships is a bridge, not an engine
Strip the branding and the shape is plain: lvector_embedding is a data
type that holds a vector in an Informix column, and lvector_bulk_sync
plus the indexing UDRs are a set of functions that copy that data to LanceDB, where
the nearest-neighbour search actually executes. That is not a native vector engine
with a convenient SQL front end. It is a data type and a copy procedure in front of
a real, separate vector store — architecturally the same shape as running Milvus,
Qdrant, or LanceDB itself as a sidecar next to Informix and syncing data into it.
HCL's own documentation, quoted throughout this page, describes exactly that
mechanism.
Which makes the question worth asking precisely: compared with a sidecar, not a native store. And on that comparison, what HCL ships does not fare well — it inherits a second storage system's operational burden without a purpose-built vector engine's operational maturity.
What the marketing says vs. what the documentation says
Public materials describing VectorBlade state: “Vectors aren't bolted on or constrained — they're first-class citizens, replicated, backed up, indexed, and governed like every other data type in the engine,” “No data duplication and no data movement,” and “ACID on vectors.” Source: Actian's VectorBlade announcement.
HCL's own product documentation, cited throughout this page, describes vectors copied to a separate filesystem store by a manual procedure, modifications to that store that are not recorded in the Informix logical log, and a standard backup that does not capture it. Both are public statements about the same product. Read the source pages linked here and judge which one describes what ships.
Native HNSW inside Informix vs. HCL Informix VectorBlade (lvector + LanceDB)
| HCL Informix VectorBlade | Informix vector (ifxtools) | |
|---|---|---|
| Where the searchable ANN index lives | A LanceDB-format table on the filesystem, outside Informix-managed chunks (IFX_LVECTOR_URI). | ✓ A BLOB in an ordinary Informix table (hnsw_index_storage), inside the same chunks as every other table. |
| Consistency with the base table | Point-in-time, as of the last lvector_bulk_sync run. Not enforced between syncs. | ✓ Continuous. A write to the row and a write to the index commit in the same transaction. |
| New writes before the next sync | Not indexed. Served by a brute-force scan over the unindexed rows, on every query. | ✓ There is no separate sync. Every committed insert is durable and searchable through the resident graph immediately. |
| Logical log coverage | None, by HCL's own documentation — lance table changes are not logged and cannot be logically recovered or replicated. | ✓ Full — the index tables are ordinary Informix tables, logged like any other. |
| HDR / RSS replication | Not covered — the log gap above rules it out for the index. | ✓ Inherited for free: standard-table semantics mean standard replication semantics. |
| Standard backup (ontape / onbar) | Does not capture the lance store. A separate, manual archive of IFX_LVECTOR_URI is HCL's documented recommendation. | ✓ Captured automatically. Nothing outside the engine to configure or remember. |
| Disaster recovery for the index | Rebuild from the Informix table via bulk sync, or restore the filesystem directory separately — both manual steps HCL documents explicitly. | ✓ Restored with the rest of the database, in the same operation, by the same team that already runs it. |
| Operational surface | Two storage systems with two different consistency models, reconciled by a procedure a human has to remember to run. | ✓ One engine. The people who already operate Informix already operate this. |
Where a bridged architecture is the right call — and where it is not
Copying vectors out to a purpose-built ANN engine is not always the wrong choice. It is the right one when the corpus outgrows what a single database node can hold resident, when the workload is genuinely a training or experimentation pipeline — the branchable, versioned dataset LanceDB is built for — or when the vector search is decoupled from the transactional system by design, with its own team owning the staleness budget.
It is the wrong call when the vector is answering a question about a row that is still being written — the exact shape of enterprise RAG over live operational data, fraud scoring against a current ledger, or semantic search over inventory that changes by the minute. There, a search index that is only ever as current as the last manual sync, cannot be replicated with the row it describes, and has to be rebuilt by hand after a restore is not a smaller version of a native index. It is a different, weaker guarantee, and the documentation above is HCL's, not ours.
The verdict, in the architect's own terms.
Is HCL Informix VectorBlade production-ready as the vector store behind live operational RAG?
No, by HCL's own documentation, not for that workload. An index that is only ever as current as the last manually invoked lvector_bulk_sync, that a standard onbar / ontape backup does not capture, and that cannot fail over with HDR or RSS because it sits outside the logical log is not a production-grade store for a row that might have just been written — enterprise RAG over live data, fraud scoring against a current ledger, inventory search that changes by the minute. That is not this page's assessment. It is what HCL's archiving and sync documentation states about the mechanism, quoted and linked throughout this page.
Where does the case rest — on interpretation, or on HCL's own words?
On HCL's own words, verifiable at the source. “Copied … to special file system files outside of Informix chunks.” “Not recorded in the Informix logical logs.” “Pivot to a brute-force search on the unindexed data.” Every one of those phrases links to the HCL page it comes from. This is not a paraphrase to check — it is a direct quotation to verify.
HCL markets VectorBlade as native and ACID. Is that inaccurate?
Compared with its own documented mechanism, yes. The public claims — “first-class citizens, replicated, backed up, indexed and governed like every other data type,” “no data duplication and no data movement,” “ACID on vectors” — describe a native access method. The documentation describes a data type plus a manual copy procedure into a separate LanceDB-format store outside the chunks, the log and the backup. Both are cited above; they describe the same product differently.
Does HCL's lvector_embedding column itself get backed up and replicated?
Yes, and that concession does not close the gap. The base column is an ordinary Informix value, covered like any other. The searchable index — the part a query actually runs against — is the LanceDB-format store, and that is the part outside the log, the backup and HDR/RSS. Conceding the column does not make the index native.
What breaks first if a team skips running lvector_bulk_sync for a while?
Nothing errors, which is worse than an error. Recall silently degrades: rows written since the last sync are still returned, but only through a brute-force scan layered on top of a stale index, getting slower and staler as the gap grows, with no documented alert and no automatic detection of how far the two stores have drifted.
What happens to the vector index in a disaster-recovery failover?
It does not fail over. By HCL's own documentation the LanceDB store sits outside the Informix logical log, so HDR and RSS cannot reach it. The documented recovery path is to rebuild it from the Informix table after the fact — a manual step that has to be added to the DR runbook, and re-tested every time the runbook is, because nothing in the engine does it automatically.
Is a bridged architecture ever the right engineering call — even given all this?
In narrow cases, yes: a corpus beyond a single node's resident memory, a genuine ML training/versioning pipeline, or a vector search deliberately decoupled from the transactional system with its own team owning the staleness budget. None of those describe enterprise RAG, fraud scoring or inventory search over live rows — the workloads this comparison is written for — and even where a bridge is the right shape, HCL's specific implementation still lacks what a deliberately built one would have: continuous sync instead of a manual batch call, and a documented HA story for the vector store instead of none.
How does the native HNSW index here compare on raw numbers, not just architecture?
That is a separate, measured comparison against PostgreSQL pgvector — recall, latency, footprint and maximum dimensions, all run on the same host with a three-way-verified harness. See the Vector search page.