SQLite-Vector
github.com/sqliteai/sqlite-vector- Category
- Developer Tools
- Rank
- No. 1063Tools index
Previous survey · No. 1055 ·
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Data, Retrieval & Knowledge
- Interfaces
- Host Plugin
- GitHub
- 1.2k stars
- Latest release
- 1.1.2
- Date
About
SQLite-Vector is an Apache-2.0 licensed SQLite extension that adds vector search to embedded databases, using SIMD distance kernels and 2/3/4-bit TurboQuant quantization for efficient exact search. It runs anywhere SQLite runs, including mobile, browser, edge, and server environments, and targets developers building RAG or semantic search directly inside a SQLite database.
What it does
A loadable C extension that turns an ordinary SQLite table into something you can run nearest-neighbour queries against. Embeddings sit in a plain binary column; you register the column once per connection with its type, length and distance metric, then query through two table functions: an exact brute-force scan, or a scan over a compressed copy built by a separate quantize step. There is no graph index to build. Every query walks every row, made fast by hand-written SIMD (single instruction, multiple data) kernels and by shrinking each vector to 8, 4, 2 or 1 bits.
Why it's ranked here
The case rests on honest numbers and portability. The project publishes a benchmark on one million 768-dimension vectors: exact search at 484 ms per query, the 8-bit signed mode at 37.6 ms with 99.5% recall at 20, or 114 ms when held to a 30 MB memory budget. The benchmark tooling refuses to print paste-ready rows for nonstandard runs and stamps the real SIMD backend itself, so the table is hard to fake. It ships Apache 2.0, with prebuilt binaries for Linux, macOS, Windows, Android and iOS, plus npm and Python packages and a WebAssembly build.
What's good
The documentation tells you when not to use its own features. It warns that the unsigned 8-bit mode collapses to 33.8% recall under cosine distance, that the default picks that mode for non-negative data, and that the 1-bit mode is a pre-filter at 10% recall, not an answer. It also concedes TurboQuant saves memory but is slower than plain 8-bit. Concurrency is handled with care: a preloaded index is reference-counted, so reloading or dropping it cannot free memory a running query is still reading. The build file documents that one test target silently skips the AVX kernels and adds a second target that actually tests them.
Tradeoffs
Search is linear in table size by design, so latency grows with every row; the only published hardware result is one Apple M5 Pro. Recall figures come from uniform random data, which the project calls a floor, so you must measure your own. The compressed copy goes stale when data changes and must be rebuilt by hand. Several options are trust-me assertions: declaring vectors normalized gives wrong distances if they are not, and binary input is not validated. Initialization must be repeated on every connection, at most 128 vector columns can be registered, and the Windows binary is x86 only. The README also funnels toward a paid managed cloud.
How to use it well
Fits apps that already live in SQLite, especially on phones, desktops or edge boxes, where a few hundred thousand to a million embeddings must be searchable offline without a separate server. Pick the signed 8-bit mode for cosine and set it explicitly, preload it if memory allows, and verify recall against the exact scan with the SQL recipe the docs supply. Use streaming mode when you need to filter by other columns. Rebuild the quantized copy after bulk writes. For tens of millions of vectors or sub-millisecond latency, a real approximate index elsewhere is the better fit.
Technical notes+
README.md documents the benchmark harness (built at -O3 with per-translation-unit SIMD flags) and the mode table: FLOAT32 exact 2930 MB / 484.4 ms, INT8 740 MB / 37.6 ms, 1BIT 99 MB / 2.5 ms, TURBO4 378 MB / 151.5 ms. The Makefile enables -mavx2/-mavx512f only for the distance-avx2 and distance-avx512 objects, leaving runtime selection to init_distance_functions(), and its comment admits the plain unittest target compiles every source in one invocation so __AVX2__ is undefined and only scalar kernels are tested; unittest-simd with EXPECT_BACKEND fixes that. src/sqlite-vector.c defines DEFAULT_MAX_MEMORY as 30 MB, MAX_TABLES 128, stores metadata in a _sqliteai_vector table, and guards the refcounted preload_index with a global sqlite3_mutex (stubbed to no-ops under SQLITE_WASM_EXTRA_INIT). src/distance-cpu.c computes BF16/F16 L2 with a LASSQ scaled sum of squares, drops NaN lanes, returns 1.0 cosine distance for zero vectors and negated dot for DOT. API.md says TurboQuant now uses one scan implementation on every CPU because per-backend float accumulation diverged by up to 1.5e-4 relative. QUANTIZATION.md gives TurboQuant memory as rows * (8 + 4 + ceil(dim * qbits / 8)) bytes. test/test_vector.c is a C assertion suite over full and quantized scans per type and distance. packages/node/package.json requires Node 16+ and ships per-platform optional binaries including musl; packages/python/pyproject.toml forces platform-specific wheels.
Observed
- License
- Apache-2.0 (LICENSE.md, also declared in both package manifests)
- Language
- C, built as a loadable SQLite extension via a Makefile
- Interfaces
- SQL scalar functions plus two table-valued scan functions; no server or CLI of its own
- Packaging
- npm package with per-platform binaries, Python platform wheels, WebAssembly build, prebuilt binaries
- Platform support
- Linux x86 and ARM, macOS x86 and ARM, Windows x86, Android, iOS
- SIMD backends
- SSE2, AVX2, AVX-512, NEON, RISC-V vector, with a scalar CPU fallback
- Search method
- Brute-force scan over full or quantized vectors; no approximate graph index
- Tests
- C unit test suite in test/test_vector.c plus a SIMD-backend test target
Read from README.md, Makefile, API.md, QUANTIZATION.md, src/sqlite-vector.c, src/distance-cpu.c, packages/python/pyproject.toml, packages/node/package.json, LICENSE.md, test/test_vector.c.
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.