Vector Database Release 0.7.0: IVF-RaBitQ, DiskANN io_uring, 40% Smaller Library

Version 0.7.0 is a broad release for this embeddable vector database. Four areas changed: the surrounding ecosystem, index algorithms, how the library gets deployed, and everyday usability. The headline items are a workspace search CLI called zvec-grep, an integration with ReMe, IVF-RaBitQ, a productionized DiskANN with io_uring and ARM64 support, runtime AVX2 and AVX512 dispatch for RaBitQ, a dynamic library about 40% smaller, musllinux wheels, prebuilt SDK binaries from CI, DocIterator, and an N-gram tokenizer for full-text search. The complete notes are on the project's GitHub release page for tag v0.7.0.

Ecosystem

zg: local-first workspace search

The new zvec-grep command-line tool searches a workspace entirely on your machine. Three layers sit behind one interface:

• ripgrep, for quick literal and regex matching
• BM25 with jieba, for lexical ranking
• HNSW vector search, for semantic lookups

Both people and AI agents are meant to use it, and it can plug into agent workflows over MCP. Anyone building RAG over a codebase, agent memory or documentation gets a single command, zg, in place of several stitched-together tools.

ReMe integration

The database now works as a file-store backend for ReMe, a memory management kit for agents. ReMe uses it for in-process HNSW approximate nearest neighbor search across agent memory files, so applications get low-latency vector retrieval without launching a separate database process.

Index algorithms

IVF-RaBitQ

RaBitQ first appeared on HNSW and Flat indexes in earlier versions. In 0.7.0 it reaches IVF indexes, offering another way to give up a little recall for a big memory saving on billion-scale data.

An IVF-RaBitQ index clusters vectors into inverted lists, and each list is quantized with RaBitQ to about one bit per dimension. The index stays compact while still supporting reranking through a refiner and scalar filtering, and it uses the same Query API as before. For workloads that fit the IVF profile, meaning large batch-style jobs or memory-limited search, it's often the cheapest option.

SIMD dispatch for RaBitQ

RaBitQ now picks its fastest code path at runtime. A CPU with AVX512 uses the AVX512 kernels, otherwise AVX2 is used, and scalar code is the last resort. One binary can therefore benefit from new hardware with no separate builds or compiler flags.

DiskANN, ready for production

DiskANN was a headline feature of v0.5.0. This release makes it faster and sturdier, and available on more platforms.

io_uring backend. On Linux 5.3 and later, DiskANN prefers io_uring to libaio. It calls the kernel directly, so building doesn't require liburing. The fallback order is io_uring, then libaio, then pread, and it degrades gracefully when a backend is missing.

Overlapped async I/O and dynamic beam. Beam search now overlaps CPU work with disk reads, and it adjusts the beam width on the fly to keep I/O busy without flooding the disk with requests. Disk-bound workloads see lower latency. A related fix to visit-filter deduplication removes redundant candidate insertions.

ARM64. DiskANN builds and runs on Linux ARM64 and on Apple Silicon Macs. On macOS it uses synchronous pread with F_NOCACHE and read-ahead disabled, while CI on Linux exercises every backend. Edge cases such as partial or short reads, EINTR and falling back between backends are handled safely.

Introspection. The active I/O backend is cached and visible through the C, C++ and Python APIs, which lets you confirm at runtime whether queries use io_uring, libaio or pread.

Better graph quality

Vamana gets an optional two-pass build. A fast first pass produces a rough graph and a second pass refines it, a good trade when recall matters more than build time.

HNSW can also build its graph from the original raw vectors supplied by an index provider, even if the index stores a quantized or transformed copy for search. Graph construction sees full precision, so quality improves, while memory at query time stays small.

Deployment

A slimmer dynamic library

Prebuilt C and C++ shared libraries are about 40% smaller on macOS ARM64. For example, libzvec_c_api.dylib goes from roughly 37 MB to 22 MB. Public APIs are unchanged, query speed is unaffected, and core search code is still compiled at -O3.

The savings come from three changes:

• compiling with -ffunction-sections -fdata-sections and letting the linker discard unused code
• exporting just the library's own public symbols, using -exported_symbols_list or --version-script
• dropping protobuf from the dependency tree altogether

Collection manifests remain byte-for-byte compatible with the earlier protobuf format. A small internal encoder and decoder now handle serialization.

musllinux wheels

There are official musllinux wheels for x86_64 and ARM64, which means it installs without trouble on Alpine Linux and other musl-based systems. Getting there needed a few musl-specific fixes. Large SIMD buffers moved off the default 128 KB thread stack, and the logger became a Meyers singleton to prevent duplicate __cxa_atexit registrations across shared libraries.

Prebuilt SDK pipeline

A GitHub Release workflow now produces ready-to-use C and C++ SDK packages. Alpha, beta and RC tags are flagged as prereleases automatically. Before anything is uploaded, each package goes through a smoke test. Desktop and musl runners compile small test programs in C and C++ and run them against the staged SDK. For Android the check is a cross-build that must link, and for iOS it's an inspection of both XCFramework slices and the header layout.

Usability

DocIterator

Agent-memory and ETL users often want to walk through every document in a collection without a query vector. DocIterator covers that. It takes a snapshot of current segments and the delete bitmap at creation, so later writes and deletes don't disturb the traversal. It works from C++, C and Python, and admission control keeps traversal and maintenance operations from overlapping.

In Python:

with collection.iter_docs(
    output_fields=["title"],   # only fetch needed scalar fields; primary key is always returned
    include_vector=False,
) as docs:
    for doc in docs:
        print(doc.id, doc.fields["title"])

N-gram tokenizer for FTS

Full-text search has a new N-gram tokenizer. It indexes overlapping character sequences of length n and ignores word boundaries. That fits phrase and substring search in short text, code identifiers and log lines, and languages where finding word boundaries is ambiguous. Set n through extra_params when creating the FTS index.

Performance

• DiskANN overlaps CPU and disk work in beam search, with the dynamic beam width holding concurrency at a sensible level.
• RaBitQ chooses AVX512 or AVX2 kernels at runtime, with no need for a single fixed build target.
• Dead-code elimination in the dynamic library gives smaller binaries, which load faster and use less resident memory, while the search kernels stay at -O3.

Other changes and fixes

• Python API: a new collection.close(), validation for empty FTS queries, topk and unknown field names, and cleaner handling of NumPy vectors.
• C++ API: public names now follow snake_case.
• C API: no more bogus 0.2.1 version string when git tags are absent.
• Search correctness: filters are validated and stale filter state is reset, and heap invariants can't be bypassed.
• K-Means: fixed the sampling weights in spherical K-MC2 and centroid normalization.
• Storage: scalar batch boundaries that don't match are handled, the final IPC chunk in the mmap store is processed properly, delete-only writing segments are persisted, and orphaned or retired segment directories get cleaned up during crash recovery and on Windows.
• Collections: reads and writes continue while Optimize runs.
• Vamana: asymmetric query metrics are respected.
• Build and CI: fewer Windows DLL exports, stale submodule patch markers removed, GitHub Actions dependencies updated, and checks run when draft PRs become ready.

Upcoming work on storage scalability, more algorithms and additional language SDKs is tracked in the public roadmap issue, number 309 in the project's GitHub repository.