Back to releases
v1.0.0

SQLite zero-config standalone mode (first public release) (v1.0.0)

Run as a single binary with a single .db file, no PostgreSQL or Redis; coexists with the production PG path, with complete retrieval and zero PG regressions.

SQLiteStandaloneFirst release

v1.0.0 is Langhuan’s first public release. The biggest change in this version isn’t a pile of new features — it’s a completely different deployment path: SQLite zero-config standalone mode, so “one binary + one .db file” is enough to run, with no hard requirement on PostgreSQL or Redis.

Prebuilt binaries for macOS (Apple Silicon / Intel), Linux, and Windows are now available from the download page — unzip and run.

Standalone: one command to start

Previously the minimum stack was PostgreSQL + pgvector + zhparser + Redis, so first impressions meant pulling up a full docker compose. Since v1.0.0 you can just run the binary:

make standalone   # or: go run ./cmd/langhuan, or ./langhuan directly

On first start it auto-provisions a SQLite database, encryption keys, and config under ~/.langhuan-data/. Open http://127.0.0.1:8080, register an admin, and start ingesting and searching.

Two stacks, side by side

Standalone mode doesn’t just swap SQLite for PostgreSQL; retrieval got dialect-level adaptation:

  • Vector retrieval: production uses pgvector (halfvec + HNSW); standalone uses sqlite-vec brute-force scan — 100% recall of the exact solution, at the cost of no ANN acceleration, best within tens of thousands of embeddings.
  • Chinese full-text: production uses PostgreSQL FTS + zhparser; standalone uses FTS5 + gse (pure-Go Chinese tokenization, dictionary embedded in the binary).
  • Queue / rate limit / OIDC state: all localized in standalone — in-memory queue, in-memory rate limiter, in-memory state store, so Redis can be disabled entirely.

Retrieval capability stays complete: vector + Chinese full-text + RRF fusion + rerank, nothing missing.

Boundaries, stated honestly

Standalone targets development, demos, and small-team trials. A few boundaries worth knowing:

  • Recommended under tens of thousands of embeddings (vector is a brute-force scan).
  • Serialized writes (SQLite single-writer lock).
  • The in-memory queue drops unfinished tasks on process exit, compensated by source cleanup and user retry.

For production concurrency and large data, use the PostgreSQL + Redis deployment.

First public release

v1.0.0 freezes the REST, MCP, auth, and error-code compatibility baseline as the publicly promised interface boundary. The whole SQLite effort held “zero PG regressions” as a hard constraint, passed two rounds of code review, and the existing PostgreSQL test suite stays green.

Implementation details live in the SQLite support spec and the architecture docs.