Docs / Blog / v0.1 release notes

v0.1 release notes — what shipped in walkindb's first public release

The API, three clients, SECURITY.md rollout, and real benchmark numbers from the €6 VPS.

Posted 2026-04-11 · 10 minute read

walkindb v0.1 is live at https://api.walkindb.com. This is the "first thing you can curl from an HN comment" release. It is deliberately not labeled v1.0 because the SECURITY.md rollout-state table still has items marked 🟡 and ⏳, and this post is honest about which ones.

If you just want the demo, the live SQL playground at walkindb.com will do. The rest of this post is what's under it.

What's in the release

The API

One HTTP endpoint. POST /sql. Send it {"sql": "..."}, get back JSON with columns, rows, rows_affected, truncated. The first call returns a session token in the X-Walkin-Session header; include it on subsequent calls to reach the same walk-in. Ten minutes after creation, walkindb deletes the file.

Two supporting endpoints: GET /healthz (liveness) and GET /openapi.json (full OpenAPI 3.1 spec — LLM-discoverable). That's the entire API surface.

Three clients

• pip install walkindb — Python SDK, stdlib-only (uses urllib, not requests/httpx), so it installs inside any agent sandbox. Client, Result, WalkinDBError. Apache-2.0.
• npm install walkindb — JavaScript / TypeScript SDK, ESM only, TypeScript types shipped in the package. Works on Node 18+, Bun, Deno, Cloudflare Workers, and any browser with fetch. Zero dependencies.
• npx walkindb-mcp — MCP server that adds walkindb_execute and walkindb_reset tools to Claude Desktop, Claude Code, Cursor, Zed, and Continue. One line in your client config.

All three are version 0.1.0, Apache-2.0, and were published the same day as the first API deployment.

Security layers that actually shipped

The full SECURITY.md model has eight layers. v0.1 ships six of them, partially or fully:

Plus an extra: an application-level SQL keyword blocklist (internal/executor/blocklist.go) that rejects ATTACH, DETACH, load_extension, readfile, writefile, fts5_*, sqlite_dbpage, zipfile, unzip, edit before the statement ever reaches SQLite. Comment-aware (strips /* */ and -- before matching), case-insensitive. This covers what Layer 2 would cover, minus the dangerous-PRAGMA denial. Once v0.2's authorizer lands, the blocklist stays as defense-in-depth.

What's deferred on purpose

• Layer 1 — SQLite compile-time hardening (SQLITE_OMIT_LOAD_EXTENSION, SQLITE_OMIT_ATTACH, DQS=0). Requires either a fork of modernc or switching to mattn/go-sqlite3 with cgo. Decision memo at launch/research-modernc-authorizer.md in the repo.
• Layer 2 — sqlite3_set_authorizer callback. Not blocked on the driver — the research memo found the C function is already compiled into modernc's lib package and reachable via a trampoline. Landing in v0.2.
• Layer 6c — separate executor process + per-instance cgroups. Nice-to-have; would tighten memory/pid caps per query. Deferred because the single-process design is simpler and the current systemd hardening is already enough for the Show HN bar.
• Layer 7 residuals — per-IP concurrent-instance cap, per-instance query cap, global circuit breaker. Easier once we have real production telemetry to calibrate against.

None of these are shipping tomorrow, and the landing page's security paragraph says so in the same language. That honesty matters more than the missing checks.

Measurements from the VPS

walkindb runs on a single OVHcloud VPS (€6/month, 2 vCPU, 8 GB RAM) in Gravelines, France. These numbers are measured on that box with the production binary, running a second walkindb instance at 127.0.0.1:9090 with rate limits cranked high, benchmarked by a Go harness that lives in bench/ in the repo. Source is open, reproduce at will.

Memory footprint

Marginal memory per walk-in: effectively zero. The share-nothing architecture means idle walk-ins hold nothing in process memory — the directory, meta.json, and db.sqlite live on disk and are read on demand.

Latency (measured locally, loopback)

These are the server's own latency, measured over loopback to exclude the internet. End-to-end from a laptop in Portugal over HTTPS to api.walkindb.com in Gravelines adds ~150–240 ms of TLS + routing.

Throughput (concurrent requests, reused session)

Saturates at ~930 rps around c=32. c=128 gets the same rate but much worse tail latency — the two vCPUs are at the edge.

Walk-in creation rate and capacity

Single-threaded walk-in creation: 59 per second. Concurrent with 8 creators: 138 per second sustained. The test provisioned 100 000 walk-ins back-to-back in 727 seconds without a single failure. Disk usage at that scale: 1.4 GB (~14 KB per walk-in). Memory at that scale: essentially unchanged — idle walk-ins cost no RAM.

Box-level state after 100 000 resident walk-ins:

• 7.1 GB of 8 GB RAM still free
• 68 GB of 72 GB disk still free
• Zero failures, zero retries, zero rate-limit hits

Projected disk ceiling given the 14 KB-per-walk-in figure: ~4.8 million walk-ins before the disk fills. Long before that, the answer is to shard to a second box — not to rewrite the architecture. The scaling post has the full methodology.

What changed in the binary between yesterday and today

A short changelog for the people who read changelogs:

• internal/executor: added sqlite3_limit suite (all 10 caps), SQL keyword blocklist, and multi-statement SQL dispatch so CREATE TABLE t; INSERT t; SELECT * FROM t returns rows instead of rows_affected. Shipped after a smoke test against the live playground caught the bug.
• internal/session: daily HMAC secret rotation with current+previous acceptance.
• internal/sandbox: new package applying Landlock on Linux, no-op on other OSes. Called from main.go after secret load and before the listener opens.
• internal/ratelimit: per-IP token buckets (separate budgets for requests vs new-instance creates), in-memory LRU capped at 10 000 IPs.
• internal/access: structured JSONL access log with exactly the 7 fields the privacy notice commits to — timestamp, source_ip, instance_id, http_method, http_status, sql_byte_length, user_agent. Never the SQL text. Daily rotation + 7-day sweep. Schema-lock unit test fires if anyone tries to add a field.
• cmd/walkindb: env-var knobs for rate-limit tuning (WALKINDB_RATE_LIMIT_REQS, WALKINDB_RATE_LIMIT_NEW_INSTANCES), secret rotation goroutine, sweeper goroutine.
• systemd unit: tightened with SystemCallFilter=@system-service plus denies for @mount @swap @reboot @raw-io @cpu-emulation @debug @obsolete @privileged @resources, plus all the standard Protect* and Restrict* directives.
• bench/: new Go benchmark harness that produced all the numbers in this post. Runs against any walkindb instance you point it at.

Test suite now at ~70 tests across 9 internal packages, all green. The load-bearing one is TestEntryFieldShapeIsExhaustive in internal/access — it fails if anyone adds a logged field without updating legal/privacy.md first.

What's next

In rough priority order:

1. Email aliases at Cloudflare Email Routing — abuse@, dmca@, security@, privacy@, legal@, hello@. The privacy notice commits to acting on abuse@ within 72 hours; that promise is only truthful once the mailbox exists.
2. DMCA designated agent registration at copyright.gov ($6, 10 minutes). US Section 512(c) safe harbor is not fully claimable until this is done.
3. Layer 2 (authorizer callback) via the trampoline path documented in launch/research-modernc-authorizer.md. A prototype may already exist in internal/authorizer/ by the time you read this.
4. Layer 1 (SQLite compile-time hardening). Likely route: stay on modernc.org/sqlite for v0.x, evaluate a mattn-based build for v1.0.
5. Layer 6c — separate executor process per query, with cgroups for memory and pid limits. Bigger refactor; probably v0.3.
6. Persistent tier — still intentionally absent. v0.1 has no paid tier of any kind. If there's demand after Show HN, expect an out-of-band email-based offering.
7. Regions — one VPS in Gravelines is enough for v0. Multi-region is a day-after problem.
8. Observability — Prometheus metrics on :9091, or a /metrics endpoint. The 7-day access logs are fine for abuse response; operational metrics need their own feed.

Trying it

# First call — provisions a walk-in, returns the session token in the header
curl -i -X POST https://api.walkindb.com/sql \
  -H "content-type: application/json" \
  -d '{"sql":"CREATE TABLE notes(id INTEGER PRIMARY KEY, body TEXT); INSERT INTO notes(body) VALUES(\"hello\"); SELECT * FROM notes"}'

That's the entire onboarding. No signup, no API key, no credit card.

Python: pip install walkindb. JavaScript: npm install walkindb. Claude Desktop / Cursor / Zed: add walkindb-mcp to your MCP config per walkindb.com/docs/mcp.

Full docs: walkindb.com/docs. Bug bounty: [email protected] — we pay proportional to impact.

v0.1 is the first release. It is not the last. Thanks for reading.

Also see

• How walkindb holds 100 000 concurrent walk-ins on a single €6 VPS — full benchmark methodology and the share-nothing architecture post
• Security model — the defense-in-depth layers referenced above
• walkindb on GitHub — source for the server, clients, MCP wrapper, docs, legal, and benchmarks
• walkindb.com — home page + live SQL playground