Blog · Browse
Every post, every week.
37 posts in the corpus. Filter by category, search the titles, or click a cell to jump to a week.
- June 2026: 5 posts
- May 2026: 24 posts
- April 2026: 8 posts
37 posts.
- JUN 2026
RedDB on a Raspberry Pi: the smallest sane install
A weekend exercise — image a Pi 5, install RedDB, load a hundred thousand rows, and see what happens when document + vector + KV + blob all live on a $80 board under the desk.
-
Cross-session task queues — AFK agents with durable resume
An AFK agent's to-do list is the worst place to keep ephemeral state. Move it to a RedDB queue with checkpoints, idempotency keys, and a watchdog and a Stop becomes a pause, a crash becomes a retry, and a machine swap becomes a noop.
-
Eval datasets in RedDB — from ad-hoc prompts to versioned regression sets
Most teams evaluate agents with a notebook full of one-off prompts that nobody re-runs. Capture every interesting turn into a RedDB table, tag it, version it, and your eval becomes a query that any model upgrade can be diffed against in seconds.
-
Sub-agent dispatch via database queue — durable parallelism across sessions
Claude Code's Task tool spawns sub-agents that die with the session. Push the work into a RedDB queue instead and workers on any machine pick it up, write results back, and the parent subscribes to completions via LISTEN/NOTIFY. Fire-and-forget becomes durable fan-out.
-
Context window economics — when memory beats reloading docs
Every CLI agent burns tokens re-reading the same files turn after turn. Put a number on the waste, work out the breakeven against a semantic-memory layer in RedDB, and show the SQL plus hook that flips the math for projects past a few thousand lines.
- MAY 2026
Multi-agent shared memory — five agents, one knowledge graph
When parallel sub-agents work on related slices of the same problem, they need a shared scratchpad with conflict resolution. A snapshot-read, first-committer-wins write pattern over RedDB gives each agent isolation while still surfacing contradictions as alerts on the orchestrator side.
-
Agent observability — traces, tokens, and costs in RedDB
Most Claude Code setups can't answer "what did the agent cost me last sprint?" or "which tools dominate p99 latency?". A PostToolUse hook that writes every tool call, token count, and cost into RedDB turns those questions into one-line SQL.
-
An MCP server for RedDB — one database, every agent CLI
The Model Context Protocol lets every modern agent CLI — Claude Code, Codex, Cursor, Gemini CLI — share the same toolbelt. Wrap RedDB once and you give all of them agent memory, document storage, and semantic search through a single endpoint. Manifest, server, wiring.
-
Building a "remember this" skill end-to-end
A 30-minute walkthrough — turn a Claude Code skill into a durable note-taker. The skill captures the current conversation slice, embeds it, writes it to RedDB, and surfaces it on the next SessionStart. Every file you need, in order.
-
Slash commands with memory — commands that learn between sessions
A Claude Code slash command is a markdown file with a shell expansion. Wire that shell call to RedDB and the command stops being a stateless macro — /remember, /forget, /recall become a tiny CRUD app the agent uses for itself.
-
Hooks that mutate state — making Claude Code hooks transactional with RedDB
A PostToolUse audit-log hook looks trivial until the agent crashes mid-turn, the network blips, or Slack 503s. Wrap the side effects in a RedDB transaction with idempotency keys and a saga for the external call, and the hook stays honest.
-
Skills as data — storing metadata, runs, and learned refinements in RedDB
Claude Code skills are static SKILL.md files today. Promote them to first-class data — metadata, execution traces, success rates — and the agent can pick the right skill for a new task with a SQL query instead of a keyword-match heuristic.
-
Agent SDK on RedDB: building custom agents with native persistence
A walk through the four surfaces of a small Agent SDK — tool registry, memory adapter, conversation log, eval hooks — backed by RedDB instead of a stack of services. Ends with a working code-review bot in under 300 lines that remembers what it has reviewed, per repository.
-
Chunking inside the engine: when the DB owns segmentation
Most RAG stacks chunk in Python glue between Postgres and a vector store. The result is a second pipeline that drifts. This post walks through what it looks like when chunking is a declarative rule attached to a column, reranking is a query operator, and the engine — not the application — owns segmentation.
-
Hybrid search done right: lexical, vector, and filter in one plan
A walk through the RedDB query planner fusing BM25, vector similarity, and a structured filter into a single execution plan — with EXPLAIN output, the cost model behind it, and what happens on the edge cases that trip up naive two-stage rerankers.
-
One WAL, four data models: how cross-modality transactions actually work
A deep dive into the shared write-ahead log that lets a document update, a vector insert, a KV write, and a blob commit land in the same transaction. Record layout, the fsync contention tradeoff, and the four mitigations we shipped before the tail latency became someone else's incident.
-
Postgres + pgvector → RedDB: a migration playbook with wall-clock numbers
A step-by-step playbook for moving a production Postgres + pgvector workload to RedDB — dual-write, embedding backfill, query translation, cutover, rollback — with measured timings from a 12M-row test corpus and the three places teams trip over.
-
Threat model: what RedDB protects against (and what it doesn't)
An honest STRIDE walkthrough of the RedDB engine and vault. What the database protects against (cold-storage breach, replicated-secret leakage, key compromise during rotation) and what it does not (compromised application process, host-level side channels, malicious operator). Gaps are named, not hidden.
-
RedDB as Claude Code's memory backend — beyond CLAUDE.md
Swap the static MEMORY.md file for a queryable, embeddable memory layer. A SessionStart hook reads top-K memories into context, a /remember slash command writes them, and RedDB stores rows, vectors, and audit log in one transaction.
-
Hello from inside the engine
A first note on what we're building and why a multi-model engine matters in 2026.
-
Stop stitching Postgres, pgvector, S3, and Redis
Every modern app you ship is four databases in a trenchcoat. Here is the bill — in failure surfaces, ops playbooks, and consistency models — that nobody costs out before signing.
-
The tradeoffs we made to fit four engines in one
Document, vector, KV and blob in the same transaction is not free. Here's the per-modality tuning surface we cut, the plugin story we sacrificed, and the cold-blob latency tail we accepted.
-
RAG without a second database
When your vectors live on the same row as the document they describe, the entire CDC-and-backfill layer of a RAG pipeline disappears — and a class of stale-retrieval bugs goes with it.
-
Per-row encryption with zero-downtime key rotation
How the vault keeps reads hot during rotation, and the one knob you should never touch in production.
-
Notes from compaction hell
Three months of LSM compaction tuning at production scale — the latency tail we measured, the four configuration changes that actually moved P99, and the one we wish we'd made on day one.
-
When NOT to migrate: a checklist
The companion piece to every migration post. A decision tree for staying on your current stack — team size, pain quantification, runway — so you do not pay migration tax for a problem you did not have.
-
GDPR right-to-erasure when your data is replicated and embedded
Article 17 across replicas, derived embeddings, backups, and WAL — what RedDB does automatically and what still needs an operator runbook.
-
Snapshot isolation, in practice
What snapshot isolation gives you, what it doesn't, the write-skew anomaly that still bites, and the one application pattern that fixes most real cases.
-
BYOK, KMS, and the boring parts of multi-tenant secrets
AWS KMS, GCP KMS, and HSM integration for RedDB — plus the three failure modes nobody writes about until they happen at 03:00.
- APR 2026
MongoDB → RedDB: the queries that change shape
Idiomatic translations from MongoDB to RedDB for the patterns that actually appear in production code — aggregation pipelines, change streams, GridFS, and the three places where the literal translation is wrong.
-
Disaster recovery for RedDB: PITR, snapshots, regional failover
An operator playbook for RedDB disaster recovery — point-in-time restore with example commands, snapshot scheduling, cross-region replication topology, the RPO/RTO numbers you can actually hit, and an honest list of what we don't yet do.
-
Out of Firebase, into a real backend
A migration playbook for teams that outgrew Firebase — auth bridge, Firestore doc model, security rules, real-time — and an honest look at what you lose when the magic console goes away.
-
The drift window: why your RAG retrieves stale chunks
A customer-visible failure mode unique to two-store RAG — source updates, queue lag, retrievals against the old embedding. Anatomy of one outage and how same-transaction writes eliminate the window.
-
Building an agent memory layer on RedDB
A copy-pasteable schema for episodic, semantic, and procedural memory in a single database — with the queries that retrieve them and the bookkeeping that keeps them honest.
-
Self-hosting RedDB: the real-world checklist
An operator-grade checklist for running RedDB on your own infrastructure — container images, k8s manifests, volume sizing, monitoring, backups, network policies, and the secrets-management decisions that bite later.
-
Why 'best of breed' loses at small scale
The ops cost of running four engines instead of one, measured in person-hours at team sizes of 2, 5, and 15 engineers. Multi-model isn't only a scale concern — it's a small-team unlock.
-
When you don't need RedDB
An honest list of workloads where Postgres + pgvector, SQLite, or a single-purpose store will serve you better than RedDB. If your shape is on this list, save yourself the migration.