Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

0.16.0 Release Notes

0.16.0 optimizes the existing IVF-Flat vector implementation (#1283). It does not introduce Lucene, HNSW, a new persisted index format or quantization.

Vector-index construction

Initialization caches each training sample’s nearest selected-centroid score. Each newly selected centroid updates that cache; previously selected centroids are not rescored during every selection round. Parallel work computes per-sample scores and Lloyd assignments. Weighted selection and centroid accumulation keep their original order, preserving existing seeded results.

PATINADB_VECTOR_BUILD_THREADS controls the shared per-process training pool: positive integers are capped at 8; 1 selects serial execution. When unset or invalid, the default is available logical CPUs minus one, bounded to 1–8. The setting is read at first training use; restart to change it. Failure to create the pool logs a warning and falls back to serial execution. Backfill persistence remains ordered and single-writer; this setting does not parallelize all of Raft.

Training logs report initialization completion and each Lloyd iteration. Search feeds decoded candidates directly into top-k selection rather than first retaining all decoded candidate vectors. This removes one intermediate buffer; it does not promise constant total RAM, a fixed index cache budget or bounded materialization in every historical storage view.

Compatibility and validation

CALL db.awaitIndexes([timeoutSeconds]) now checks local index readiness, without output columns. Synchronous index maintenance normally needs no wait; pending deferred builds obey the timeout and query cancellation. It is not a replication barrier. See Procedures. The compatibility reference also explains deliberate static-label/type syntax, client-side grouping, unsupported index hints/scoped CALL, and supported scalar vector similarity.

Measured on the local Ryzen 7 3800X / NVMe fixture with 334,770 real Jira summary vectors (#1283, 2026-09-09): the complete 256D index build drops from 3429.950 s to 72.759 s (47.14 times faster), using eight training workers and unchanged index parameters. Peak build memory stays about 1.18 GiB. Warm loopback Bolt p90 is 22.886 ms for Top-10 and 23.402 ms for Top-20; sampled recall against the same exact oracle remains 96.719% / 94.844%. These are single-client measurements on this fixture, not a 10M-vector guarantee. The source-tree ledger docs/vector-benchmark-1283.md records hashes, commands, 512D results, RAM and the intentionally interrupted legacy 512D baseline.

  • Existing index definitions and similarity scores are unchanged.
  • Reference tests compare centroid bits for cosine/euclidean, different worker counts and seeds, duplicates, empty/identical inputs and cluster counts.
  • An operation-count test guards against reintroducing repeated initialization scoring. The optional timing benchmark compares the original implementation with the optimized one; wall-clock thresholds are not a flaky CI assertion.
  • vector_training benchmarks a retained real database and checks its trained definition against the existing reference without replacing the index.
  • The new openCypher Compatibility Reference documents supported, partial and unsupported forms. Its TCK inventory is explicitly dated to the reviewed 0.15.1 core revision, not a new 0.16.0 language-conformance certification.

These changes do not close the existing large-scale backup/restore, cold learner onboarding or 10M-vector qualification gaps. A version bump is not a production release approval. See Limitations.