Skip to content

RedDB navigation

Engineering · · By RedDB team · 1 min read

Hello from inside the engine

A first note on what we're building and why a multi-model engine matters in 2026.

Why another database

Most teams glue together three or four engines to ship a single product: a row store for OLTP, a search index for retrieval, a vector store for RAG, an object store for blobs. Each one has its own consistency model, its own failure surface, its own ops playbook.

RedDB collapses these into one engine with one transactional boundary. You write once, you query across modalities, you don’t reconcile.

What this blog will cover

  • Internals of the storage layer — LSM trees, segment compaction, snapshot isolation.
  • RAG primitives that live next to your transactional data.
  • The vault: per-row encryption with key rotation that doesn’t require downtime.
  • Honest notes on what we got wrong before 1.0.

Subscribe

This is the first post. Grab the Atom feed and we’ll show up in your reader as new pieces land.

Get the next dispatch.

New essays on multi-model storage, RAG, agents, security. No spam.

No spam. Unsubscribe anytime.

RedDB Cloud

Join the private beta.

One-click managed deploy. Free during beta. Founding pricing locked at GA.

Keep reading

More from the engine.

  1. 01 Engineering · · 11 min 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.
  2. 02 Engineering · · 8 min 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.
  3. 03 Engineering · · 14 min 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.