A database your agent gets without signing up.

The database for agents. A single HTTP call provisions a private database — talk to it in SQL, as a key–value store, or as documents. 10-minute TTL. No API key, no credit card, no form.

~/ terminal
# 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.

Three ways to talk to it

Agents don't all think in tables. Some want a key and a value. Some want to throw a JSON blob somewhere. Same walk-in, same 10-minute file — pick the shape that fits.

# Tables, joins, indexes, FTS5 — a real SQLite file
curl -X POST https://api.walkindb.com/sql \
  -H "content-type: application/json" \
  -d '{"sql":"SELECT name, lives FROM cats WHERE lives > 7"}'

# → {"columns":["name","lives"],"rows":[["ada",9]]}

Live today.Full SQLite. The playground below runs against this exact endpoint.

One file, three doors. All three run on the same SQLite database inside your walk-in — so a key you SET through /kv is a row you can SELECT through /sql, and a document you store is queryable with a join. No sync, no second service, no separate bill. When the 10 minutes are up, all of it disappears together.

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.

live playground · api.walkindb.com
no walk-in yet
try:
⌘/ctrl + enter to run

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

  1. POST your first SQL query No headers, no token. A fresh private SQLite file is provisioned and the query runs.
  2. Get a session token back Returned in the X-Walkin-Session response header. Include it on subsequent requests to reach the same database.
  3. 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.

Bug bounty: if you find a way past any of it, email [email protected] — we'll pay a bounty proportional to impact.

Install

~/ terminal
# Python
pip install walkindb

# JavaScript / TypeScript
npm install walkindb

# Or just curl — no SDK required