Introduction

quicSQL is network SQLite for every language. It takes a SQLite database — a plain file, an in-memory database, or an encrypted-and-compressed vfs/vault container — and turns it into an authenticated, multi-tenant network service that TypeScript, Python, PHP, Go, and anything with an HTTP client can query.

Every database it serves speaks two protocols over one handler: a dead-simple native JSON API (POST /<db>/query — thin enough for curl), and the libSQL Hrana protocol — so the existing libSQL / Turso SDK ecosystem connects to quicSQL by URL alone, interactive transactions included. Both are served across the whole transport matrix: HTTP/1.1, cleartext h2c, HTTP/2 over TLS, HTTP/3 over QUIC, and Unix domain sockets.

The design rests on one discipline: the server owns each database as one long-lived open handle and fans many network clients into it. That single-owner rule is what makes an encrypted vault file safely shareable — quicSQL opens it once and multiplexes every client through it, so the database becomes a network service without ever weakening what’s written to disk.

Authentication, per-database authorization, a control plane, and observability are built in. quicSQL itself is built on gosqlite and is pure Go — no CGo, one static binary — which is why deploying it is copying one file (or pulling one small container image).

The guides

Beyond the guides

• examples/clients/ — runnable programs in TypeScript, Python, and PHP (plus zero-dependency variants) that assert their results and run in CI against a real server.
• pkg.go.dev/quicsql.net — the Go API reference: the client, the database/sql driver, and the embeddable serverd.
• examples/ — demo starts a three-database server across every transport and benchmarks each protocol; auth exercises the full authentication + authorization matrix, denial paths included.
• LiteORM — the declarative Go data layer that runs over quicSQL unchanged, including typed vector / full-text / hybrid search.