Is embedding zvec considered in the roadmap?

[johnnychen94]

SQLite3 provides sqlite3.c, which allows other projects to embed it directly into the compiled binary without needing external DLL or SO files. This feature is particularly beneficial for applications that aim for a single binary distribution.

Does zvec plan to support this embedding option or include it in its target feature set? Or will it always rely on deploying prebuilt .so files?

If zvec plans to support it, I would be happy to help explore the possibilities and build a demo.

Background: We currently embed SQLite in our AI agent product, but using the SQLite vector extension is not license-friendly for our commercial products. As a result, we are considering alternatives. A single binary distribution is an essential feature for our product.

[egolearner]

Thanks for the interest and great question!

We've looked into the SQLite-style amalgamation approach, but there are a few fundamental obstacles that make it impractical for zvec:

1. Heavy third-party dependencies — zvec depends on RocksDB, Apache Arrow (Parquet/Compute/Dataset/Acero), Protobuf, ANTLR4, LZ4, CRoaring, and more. SQLite's amalgamation works because it has zero external dependencies. Merging all of these into a single file is not realistic.

2. C++17 vs pure C — zvec is a C++17 project with heavy use of templates, STL, and namespaces. C++ amalgamation is extremely fragile due to ODR rules and template instantiation conflicts, unlike SQLite's clean C codebase.

3. Platform-specific compilation — Some source files require different compiler flags (e.g., SSE4.1, AVX2, AVX512 for SIMD acceleration). A single-file compilation cannot accommodate per-file flags.

4. Build-time code generation — Protobuf .proto files are compiled during the build, which requires a build system and cannot be statically merged.

That said, your core requirement — single binary distribution without external .so files — is absolutely achievable via static linking. Our build system already produces static library targets (_static variants) and a "fat" shared library (libzvec_c_api) that bundles all dependencies with --whole-archive. A pre-built static fat library (libzvec_c_api.a) plus the C header (c_api.h) would let you link everything into a single binary. We are tracking this in #390 — which is exactly about providing pre-built static (.a) and shared (.so/.dylib) libraries in release assets. This would cover your use case. Please follow and comment there if you have specific platform requirements!

Of course, if you have ideas or approaches to make amalgamation work despite these constraints, we'd love to hear them — feel free to continue the discussion here.