Sizing & deployment¶
How much disk and RAM Artesian needs, and how to run a shared vector backend as a service.
All figures are order-of-magnitude estimates — actual usage depends on the embedding model,
the average note/chunk size, and the payload you store. Use them to provision, then measure with
artesian doctor and your backend's own metrics.
What consumes space¶
A unit of memory is a chunk (Markdown is section-chunked on store), embedded into one vector. Per chunk:
- Vector —
dim × 4 bytes(f32). The pinned defaultintfloat/multilingual-e5-smallis 384-d → ~1.5 KB.multilingual-e5-largeis 1024-d → ~4 KB (≈2.7×). - ANN graph (Qdrant/HNSW,
m=16) — roughly2 × m × 4 bytesof links → ~0.1–0.5 KB. - Payload — the chunk text + metadata (tags, scope, ids, timestamps) → ~0.5–2 KB typical.
- OKF Markdown copy (Files backend, or the OKF mirror) — the human-readable source on disk.
So budget ~2–4 KB per chunk on disk for a vector backend, and a few hundred bytes for the Files backend (text only, no vectors).
Sizing by scale¶
Reference: e5-small (384-d), ~1.5 chunks per note, ~1 KB payload/chunk. "Records" = chunks.
| Scenario | Chunks | Files (md only) | sqlite-vec (local) | Qdrant (shared) |
|---|---|---|---|---|
| 1 user | 10⁴–10⁵ | ~5–50 MB disk, trivial RAM | ~30–300 MB disk, tens of MB RAM | ~50–400 MB disk, ~0.2–0.5 GB RAM |
| Several users (≈5, own collections) | ~5×10⁴–5×10⁵ | ~25–250 MB | ~150 MB–1.5 GB disk | ~0.3–2 GB disk, ~0.5–1.5 GB RAM |
| Team (≈20, shared projects) | ~2×10⁵–2×10⁶ | ~0.1–1 GB | not recommended past ~10⁶ | ~1–8 GB disk, ~2–6 GB RAM |
Notes:
- RAM is the Qdrant lever, not disk. Qdrant keeps vectors + HNSW resident for low-latency
search; with
mmapit can spill cold data to disk. Scalar quantization (int8) cuts the resident vector footprint ~4× at a small recall cost — turn it on for large collections. - Embeddings are local and token-free. The only hot-path cost is CPU embedding of the query (~10–50 ms on a laptop CPU); writes embed once. No external API, no token spend.
- sqlite-vec scales to ~10⁵–10⁶ comfortably for a single user / small team and needs no server. Past that, or for true multi-writer sharing, move to Qdrant.
- Files backend has no vectors — it is for zero-infra, fully inspectable memory; search is keyword/lexical, so size it only for the Markdown.
Rule of thumb: per active user, plan ~50–400 MB disk and ~0.3 GB RAM on Qdrant; multiply by users for a shared deployment and add headroom for HNSW + payload growth.
Running Qdrant as a service (shared / cloud)¶
A shared Qdrant lets several machines and agents read/write one memory. Generic recipe — no host-specific values; keep endpoints and the API key in your local config, never in a repo.
1. Compose¶
# docker-compose.yml (Docker / OrbStack / Podman)
services:
qdrant:
image: qdrant/qdrant:latest
restart: unless-stopped
ports:
- "6333:6333" # REST
- "6334:6334" # gRPC
volumes:
- ./qdrant-storage:/qdrant/storage # bind to a real disk you back up
environment:
QDRANT__SERVICE__API_KEY: "${QDRANT_API_KEY}" # from your env, not committed
QDRANT_API_KEY="$(openssl rand -hex 32)" docker compose up -d
curl -fsS -H "api-key: $QDRANT_API_KEY" http://localhost:6333/healthz && echo " ok"
2. Point Artesian at it¶
export QDRANT_API_KEY="…" # also persist to your shell rc; init's wrapper sources it
artesian init --backend qdrant --project my-project \
--qdrant-url http://HOST:6333 --qdrant-api-key-env QDRANT_API_KEY
init registers the MCP server (Claude Code user scope, Codex, Zed) via the
run-artesian-mcp.sh wrapper so the API key reaches the server even though MCP clients launch it
without your login shell. See onboarding.md.
3. Share over the network¶
- Several agents on a LAN can share one MCP server over streamable HTTP:
artesian-mcp --transport http --bind 0.0.0.0:8080 --backend qdrant --collection my-project(build with--features http). Bind to a trusted interface only. - Off-LAN access: front Qdrant/MCP with your own reverse proxy + TLS, or ride a private overlay (Tailscale/WireGuard). Do not expose Qdrant publicly without auth + transport security — the API key is the only gate at the Qdrant layer.
4. Security & ops¶
- Auth: always set
QDRANT__SERVICE__API_KEY. Keep it in env / a0600file, never in git. - Isolation: one collection per project (default) gives hard tenant isolation and simple
routing;
user_idpayload metadata adds per-user scoping inside a shared collection. - Backups: schedule the Qdrant snapshot API to a backed-up volume; the storage bind-mount should already live on durable disk.
- Upgrades: the binary upgrades independently of the data —
artesian updateswaps the binary; config, MCP registrations, and stored vectors persist. Runartesian doctorafter. - Capacity guardrail: enable scalar quantization and
mmapfor large collections; watch Qdrant RAM, not disk, as the first limit.
See also backends.md, concurrency.md, upgrades.md.