# VexDB Lite: the same vector index shipped for PostgreSQL, DuckDB and SQLite

> One graph index and one pair of quantization kernels compiled into three database backends, with a capability matrix that grades itself against a commercial edition.

**VexDB-THU/VexDB-Lite** — A cross-platform vector database, which can be integrated into existing databases as a plugin.

- Repository: https://github.com/VexDB-THU/VexDB-Lite
- Website: https://vexdb.com
- Stars: 2,327 · Forks: 361
- Language: C++
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/vexdb-thu-vexdb-lite

## Three backends, one index, two quantization kernels

The project describes itself as a vector similarity search engine for PostgreSQL, DuckDB and SQLite, and the reason to believe that rather than treat it as marketing is in the next sentence: the backends share the same graph index algorithm, SIMD distance dispatch, and PQ and RaBitQ quantization kernels.

So this is not three independent implementations of vector search. It is one core with three adapters, which changes what you should expect from a new database target: the index behaviour, the distance semantics and the quantization behaviour should be consistent across all three, while the surrounding conventions differ because each database differs.

The latest release is v0.0.17. Its packaging covers PostgreSQL 16 through 19 for Linux on x86_64 and AArch64, DuckDB v1.5.2 for the same two architectures, and SQLite for Linux, macOS, iOS, Android and WASM, with a SHA256SUMS.txt covering all 30 release archives.

The release note for that version is in Chinese and describes a cross-engine update: a new SQLite adapter layer unifying PQ and RaBitQ quantization across PostgreSQL, DuckDB and SQLite, plus stronger DuckDB recovery, parallel builds in PostgreSQL, and a complete release pipeline. It also mentions a fix to RaBitQ cross-architecture checksum misdetection so that older index files load correctly on both x86_64 and AArch64, and an extension of the SQL version to 1.1 with an upgrade script from 1.0.

That cross-architecture detail is worth pausing on. A quantized index whose storage format is tied to one CPU architecture is a portability problem for anyone moving between an x86 build host and an ARM production host, and the fix means you can copy an index file between them.

## The PostgreSQL backend is the most complete of the three

The PostgreSQL adapter has the largest feature list, and it starts with a type and moves outward to a runtime setting. It provides a `floatvector(N)` type, three distance functions with their operators, a set of scalar helpers, and an index method.

The distances are l2_distance with the `<->` operator, cosine_distance with `<=>`, and inner_product with the note that you should use `<~>` for negative inner product, which is the MIPS form. The scalar helpers are `vector_dims()`, `vector_norm()`, `l2_normalize()` and `vexdb_index_info()`, and the index is created with `CREATE INDEX ... USING vexdb_graph`.

Index options are where the tuning lives: `m`, `ef_construction`, `parallel_workers` for parallel builds, `quantizer` taking either `pq` or `rabitq`, `pq_m`, and `memory_mode`. The README states that PQ and RaBitQ offer code-only storage, and that setting `memory_mode='compact'` makes quantizer activation mandatory, which is the honest way to describe a mode where you cannot turn the feature off.

Underneath there is an optimizer rewrite into an ANN index scan, a shared-memory vector buffer cache, and parallel index build. Two runtime settings are exposed, `vexdb.ef_search` and `vexdb.vec_architecture`, the latter being how you tell it which SIMD path to use.

The DuckDB adapter is close but not identical. It uses `GRAPH_INDEX` on `FLOAT[N]` columns rather than a custom type, rewrites into a `VEXDB_INDEX_SCAN` instead of an ANN index scan, and carries four runtime settings rather than two: `vexdb_ef_search`, `vexdb_brute_force_threshold`, `vexdb_pq_search_mode` and `vexdb_pq_refine_k_factor`. It also supports metadata filtering directly in the index definition.

One operator difference is worth noting because it will cost you an afternoon if you copy SQL between the two backends. `<#>` is unavailable in DuckDB because `#` clashes with its comment syntax, so negative inner product uses `<~>`, the same meaning as in PostgreSQL.

## PQ falls back to a plain index when it cannot be built, and says so

The quantizer story is where this project is more candid than most, and the candid part is the fallback behaviour.

The README documents a memory requirement as a SQL comment rather than prose. Product quantized index construction needs a training budget:

```sql
SET maintenance_work_mem = '2GB';   -- required; low memory falls back to a plain graph index
```

Then it lists the current v1 behaviour: if there are fewer than 256 training samples, or the memory build budget is too low, PQ falls back to a plain graph index with a NOTICE. That is a good default, because the failure mode is an unquantized index rather than a wrong index, and the NOTICE means you find out.

The same kernels serve RaBitQ, which is described as quantized graph traversal with code-only index storage. On PostgreSQL, RaBitQ supports parallel builds, queries, persistence and mutation scenarios according to the release notes. On DuckDB, the README notes that compact RaBitQ still traverses the graph using quantized codes, which is a subtle and important distinction: compact storage changes what is kept on disk, not necessarily how the graph is walked.

The DuckDB persistence story is worth contrasting explicitly, because the README does it in a footnote. VSS persistence is marked experimental, with WAL recovery not implemented and unexpected shutdowns potentially causing index corruption. VexDB-Lite persists via DuckDB's standard serialization. The same footnote marker applies to the disk-backed index row, where VSS carries the dagger and VexDB-Lite does not.

If you are evaluating a vector extension for DuckDB specifically, that single footnote is likely the most consequential line in the document.

## The capability matrix grades the free edition against the paid one

Section 2 of the README is a comparison table with three columns: PGVector, VexDB-Lite as the open-source edition, and VexDB as the commercial edition. The author uses a three-state notation, with a check for supported, a half-filled circle for coming soon, and a cross for not included in the open-source edition.

Reading it honestly, the commercial edition has features the free one does not, in a specific and recognisable cluster. Under graph index enhancement, async insert for write-heavy workloads, graph sharding for large-scale vector sets on small-memory machines, and subgraph index build are all commercial-only. Under cache, the bulk buffer for full in-memory vector throughput and the async I/O cache for disk-to-cache reads under memory pressure are both commercial-only. Auto quantization, described as background auto-enable supporting empty-table index build, is commercial-only. Parallel vacuum for index cleanup and reclaim is commercial-only, as is primary-replica HA with synchronous replication and backup restore.

Two data types are marked as coming soon rather than absent: halfvector at float16 and int8vector at int8. Both are marked as supported in the commercial column.

This is unusual and to the project's credit. A README that graded itself against its own paid edition, listing what you cannot get, is a document written by someone who expects you to read it. It also tells you something about the design centre of gravity: the free edition is built for a workload where you rebuild the index, rather than for one where a large index must be maintained indefinitely on a machine that cannot hold it in memory.

The DuckDB comparison table uses the same notation against DuckDB VSS, and there the trade goes the other way in one row: index compaction to reclaim space from soft-deleted entries is marked supported for VSS and absent for VexDB-Lite.

## SQLite gets virtual tables, and the rest is in the subdirectories

The SQLite adapter is the newest of the three, added in v0.0.17, and its model is different from the other two because SQLite has no extension type system in the Postgres sense. Instead it uses `GRAPH_INDEX` virtual tables with shadow-table persistence, which is how SQLite virtual tables store their state.

Its feature list covers L2, cosine and inner-product search with vectors supplied as JSON or as a float32 BLOB, incremental insert, update, delete, transaction rollback and reopen recovery, metadata filtering, `LIMIT` pushdown, and parallel graph construction. Quantization works in full or compact memory mode. For distribution there is a loadable desktop extension plus static registration for iOS, Android and WASM, which is the combination that makes embedding a vector index in a mobile app possible rather than theoretical.

The root README is explicit about its own scope: it is a project-level overview and build guide, and the full API and build guide for DuckDB lives in `vexdb_duckdb/README.md` with the SQLite equivalent in `vexdb_sqlite/README.md`.

The tree supports that structure, with one directory per backend: `vexdb_pg/`, `vexdb_duckdb/` and `vexdb_sqlite/`, alongside `common/`, `community/`, `examples/`, `tests/`, `thirdparties/`, `release/` and `docs/`. There is a Chinese README alongside the English one, and build scripts at the root as `build.sh`, `build_duck.sh` and `build_sqlite.sh`.

The Makefile carries a warning worth passing on, because it is the kind of thing that costs an afternoon. It says the root Makefile is only for the duckdb community-extension CI, which checks out this repository along with duckdb and extension-ci-tools as sibling directories, and that local development and releases should use `./build_duck.sh` instead. In other words, the default build entry point is not the one you want locally.

## Conclusion

VexDB Lite's real proposition is that one index implementation, one distance dispatch layer and one pair of quantization kernels serve three quite different databases, and that the author publishes a candid feature matrix separating what is free from what is not. Read that matrix before evaluating the project, because several things a vector index needs at scale, primary-replica replication, parallel vacuum, graph sharding and automatic quantization, are marked as commercial-only, and the halfvector and int8vector types are still marked as coming soon. The PostgreSQL backend is the most complete of the three, and the DuckDB backend has the most interesting persistence story. Start by installing the extension for your database and building an unquantized index, since the README is explicit that quantized builds fall back to a plain graph index when training data or memory is insufficient.

## FAQ

### Which databases does VexDB Lite support?

Three, from one shared core. PostgreSQL gets a floatvector(N) type and a vexdb_graph index method, DuckDB gets GRAPH_INDEX on FLOAT[N] columns, and SQLite gets GRAPH_INDEX virtual tables with shadow-table persistence. The graph index algorithm, SIMD distance dispatch and the PQ and RaBitQ quantization kernels are shared across all three.

### Is VexDB Lite free or is there a paid version?

Both. The README includes a capability matrix with three columns comparing PGVector, VexDB-Lite as the open-source edition, and VexDB as the commercial edition, using check, half-filled circle and cross for supported, coming soon and not included. Graph sharding, async insert, bulk and async I/O caches, auto quantization, parallel vacuum and primary-replica HA are all commercial-only.

### What happens if product quantization cannot be built?

It falls back to a plain graph index and emits a NOTICE. The README lists two triggers: fewer than 256 training samples, or a memory build budget that is too low, which is why it recommends setting maintenance_work_mem to something like 2GB before building a PQ index.

### Does the DuckDB vector index survive a restart?

Yes, and that is one of the differences the README draws against DuckDB VSS. VexDB-Lite persists through DuckDB's standard serialization, whereas VSS persistence is marked experimental, with WAL recovery not implemented and unexpected shutdowns potentially causing index corruption.

## Sources

- [License: MIT](https://github.com/VexDB-THU/VexDB-Lite/blob/main/LICENSE)
- [Project website](https://vexdb.com)
- [README](https://github.com/VexDB-THU/VexDB-Lite/blob/main/README.md)
- [Releases](https://github.com/VexDB-THU/VexDB-Lite/releases)
- [VexDB-THU/VexDB-Lite on GitHub](https://github.com/VexDB-THU/VexDB-Lite)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vexdb-thu-vexdb-lite