A SQL database your agent gets without signing up.
The database for agents. A single HTTP call provisions a private SQL database. 10-minute TTL. No API key, no credit card, no form.
# First request — -i prints response headers so you can see the session token 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\")"}' # → HTTP/2 200 # → x-walkin-session: wkn_AZ159u9PdmS97ks7FnSmnRc6... # → x-walkin-ttl: 1775868670 # → {"rows_affected":1} # Subsequent requests reuse the token — same database, same 10-min TTL curl -X POST https://api.walkindb.com/sql \ -H "X-Walkin-Session: wkn_AZ159u9PdmS97ks7FnSmnRc6..." \ -H "content-type: application/json" \ -d '{"sql":"SELECT * FROM notes"}' # → {"columns":["id","body"],"rows":[[1,"hello"]],"rows_affected":0} # 10 minutes later, the database is gone. That's the feature.
It's a real SQLite database. CREATE TABLE, joins, indexes, FTS5 — all real. It's just opinionated about ownership: you don't own the data, and you can't keep it.
Or just run SQL right here
The panel below hits api.walkindb.com from your browser, using the exact same POST /sql the curl example above calls. Your session token is stashed in sessionStorage, so your walk-in survives page reloads until its 10-minute TTL is up. Click a preset, hit run, watch real SQLite return real rows.
The last preset (try something forbidden) is there to show the keyword blocklist doing its job — you’ll see a 400 with forbidden sql keyword: load_extension, which is Layer 2 of the defense model catching an attack before SQLite ever sees the statement.
Why this exists
LLM agents can't sign up for anything. Ask Claude or GPT to "use a database," and you get to watch it hallucinate its way through a signup form it was never going to complete. Every existing managed database assumes there's a human with a credit card on the other end. There isn't.
walkindb is what you reach for when your agent needs a place to scribble state for the next five minutes and move on. Full SQL, real isolation, zero friction.
How it works
- POST your first SQL query No headers, no token. A fresh private SQLite file is provisioned and the query runs.
-
Get a session token back
Returned in the
X-Walkin-Sessionresponse header. Include it on subsequent requests to reach the same database. - 10 minutes later, the file is deleted TTL is non-negotiable. Need persistence? Use a different database. walkindb is the one you reach for when you want the data gone.
What it is and isn't
✓ what it is
- Full SQLite per instance
- HTTP/JSON — curl works
- Python & JS SDKs
- MCP server for Claude Code, Cursor, Zed
- Apache 2.0 open source
✗ what it isn't
- Not a durable database
- Not for PII or regulated data
- Not a Postgres replacement
- Not pay-to-start — ever
Security
Exposing raw SQL to unauthenticated callers is obviously the interesting part. The defense is layered. Live today: a sqlite3_set_authorizer callback enforcing PRAGMA and function allowlists at the SQLite AST level, a 2-second wall-clock query timeout, a 10 MB max_page_count per instance, the full per-connection sqlite3_limit suite (VDBE_OP=500k, SQL_LENGTH=8k, EXPR_DEPTH=50, COMPOUND_SELECT=10, LIMIT_ATTACHED=0, and six more), an application keyword blocklist rejecting ATTACH, load_extension, readfile, writefile, and the fts5_* family, a Landlock filesystem jail that confines the process to /var/walkindb/** at the kernel level, a seccomp-bpf syscall allowlist via systemd, per-IP rate limits, isolated per-session SQLite files, HMAC-signed session tokens with daily secret rotation, and 404-on-any-session-failure to prevent enumeration. Still rolling out: SQLite compile-time hardening (no LOAD_EXTENSION, no ATTACH at the engine level) and the separate executor process with per-instance cgroups. Full model and rollout state in SECURITY.md.
Install
# Python pip install walkindb # JavaScript / TypeScript npm install walkindb # Or just curl — no SDK required