The retrieval tier now runs vector search across four database backends — Postgres with pgvector, Qdrant, Redis, and, as of this release, Informix — behind one interface, so an application chooses its store without changing how it queries. This release adds the Informix backend and, separately, gives pgvector ingestion explicit control over when its similarity index is maintained.
Informix vector backend
- Native vector storage. A new Informix vector-database backend uses the engine's vector DataBlade for collection management, vector and metadata CRUD, and similarity search, joining pgvector, Qdrant, Redis and the in-memory store.
- Exact and payload search. The backend supports exact-match search through a brute-force scan and custom distance metrics, with payload schemas alongside the vectors.
Index lifecycle for bulk loads
- Drop before, rebuild after. The pgvector HNSW index is created at collection time and stays live during ingestion, so every inserted row pays an incremental graph insertion. A caller can now bracket a bulk load to drop the index first and rebuild it once at the end.
- Backend-honest primitives. The drop and rebuild hooks are real index operations on pgvector; Qdrant, Redis and the in-memory store implement explicit no-ops, each documenting why its index cannot or need not be dropped.
Incremental ingestion is unchanged, so small additions do not rebuild the whole index; the bracket is opt-in for the bulk case where the per-row cost dominates.