The vector tier's maximum dimension is raised from 2,048 to 3,072 to support OpenAI's text-embedding-3-large model at its native size. Higher dimensionality lifts retrieval quality on semantically dense corpora — legal text, technical documentation, medical narratives — at the cost of additional storage and query memory. The change is transparent to application code : the embedding model is configuration, the column declaration is a single integer, and the HNSW index parameters scale automatically.
Cross-engine HNSW benchmarks
This release ships a benchmark suite that runs identical workloads against the Informix HNSW access method and the PostgreSQL pgvector extension. The suite measures recall@10, query latency at p50 / p95 / p99, and index build time at three corpus sizes — 1,000, 5,000 and 10,000 rows — with embedding dimensions of 768, 1,536 and 3,072.
- Correctness parity. Both engines return the same top-k set on every test query within the recall-at-10 tolerance the HNSW algorithm guarantees ; differences are purely operational, not functional.
- Latency characteristics. Both engines hold p95 query latency under 10 ms at 10,000 rows and 3,072 dimensions on a 4-vCPU node ; the numbers inform topology decisions (where the vector index lives in a multi-engine deployment) rather than an either-or product choice.
- Build cost. Index construction scales linearly with corpus size in both engines ;
ef_constructionandmdrive the trade-off between build time and query recall identically.
Why dual-engine matters
Customers running PostgreSQL for the transactional workload get pgvector ; customers running Informix get the native HNSW access method ; both surface the same SQL — VECTOR column type, cosine / Euclidean / inner-product operators, identical index parameters. Embedding choice (provider × dimension) is configuration ; engine choice is operational ; application code is uniform across both axes. A workload that starts on PostgreSQL pgvector can migrate to Informix HNSW without a rewrite.