- engineering 21
- agents 14
- claude-code 12
- rag 10
- memory 7
- architecture 6
- operations 5
- migration 4
- security 4
- hooks 3
- vault 3
- durability 2
- honest-tradeoffs 2
- multi-agent 2
- query-planner 2
- queues 2
- self-hosting 2
- skills 2
- storage 2
- transactions 2
- afk 1
- chunking 1
- compliance 1
- concurrency 1
- context-engineering 1
- cost 1
- cost-tracking 1
- data 1
- decision-frameworks 1
- disaster-recovery 1
- evals 1
- firebase 1
- hardware 1
- incident 1
- intro 1
- isolation 1
- kubernetes 1
- learning 1
- manifesto 1
- mcp 1
- mongodb 1
- observability 1
- ops 1
- performance 1
- persistence 1
- pgvector 1
- postgres 1
- regression-testing 1
- sagas 1
- sdk 1
- search 1
- slash-commands 1
- stride 1
- threat-model 1
- tutorial 1
- vector 1
- wal 1
- 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.
- MAY 2026
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.
-
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.
-
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.
-
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.
- 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.