RedDB on a Raspberry Pi: the smallest sane install

The pitch we keep making is that RedDB collapses four engines into one — document, vector, KV, blob — sharing one WAL, one auth surface, one ordered cursor for change capture. That story sounds different on a server with 64 cores and 512 GB of RAM than it does on a Raspberry Pi 5 that draws less power than the desk lamp it sits next to.

So we put one on a Pi 5 for a weekend. This is the playbook and the numbers.

What you need

• Raspberry Pi 5, 8 GB model. The 4 GB will technically run but the HNSW index for the demo dataset spills under memory pressure and your numbers will be noise.
• A real SSD over USB 3, or an NVMe HAT. Do not run this on the microSD card. RedDB’s WAL is fsync-heavy; an SD card will both bottleneck writes and wear out in a month.
• The active cooler. The CPU will sit at 65–70 °C under load and will throttle without it.

Total cost of the rig as we built it: roughly $130 for the Pi + cooler + power supply + 256 GB NVMe + HAT. Less than a single month of the smallest managed-Postgres tier on any cloud.

Image and install

We used the 64-bit Pi OS Lite release, no desktop. Flash it with the official imager, enable SSH from the imager’s settings pane before writing, and boot.

Then:

ssh pi@reddb-pi.local
sudo apt update && sudo apt install -y curl
curl -fsSL https://get.reddb.io/install.sh | sh

The install script detects aarch64, pulls the ARM64 build, drops a reddb binary in /usr/local/bin, and writes a systemd unit at /etc/systemd/system/reddb.service pointing the data directory at /var/lib/reddb. If you mounted the NVMe at /mnt/nvme, point the data dir there instead before starting:

sudo sed -i 's|/var/lib/reddb|/mnt/nvme/reddb|' /etc/systemd/system/reddb.service
sudo systemctl daemon-reload
sudo systemctl enable --now reddb

Health check:

curl http://localhost:7878/health
# {"status":"ok","version":"...","uptime_ms":1843}

That is the whole install. There is no second engine to provision, no extension to compile, no sidecar to wire up.

Load a dataset

We used a tiny slice of an open product catalog — 100,000 rows, each with a title, a 256-character description, and a 384-dimensional embedding generated locally with all-MiniLM-L6-v2 (which itself runs on the Pi, slowly but it runs).

Create the table and the index:

CREATE TABLE products (
  id          UUID PRIMARY KEY,
  title       TEXT NOT NULL,
  description TEXT NOT NULL,
  price_cents INT NOT NULL,
  embedding   VECTOR(384) NOT NULL
);

CREATE INDEX products_embedding_idx
  ON products
  USING hnsw (embedding vector_cosine_ops);

Bulk-load over the line-delimited JSON import path:

reddb import --table products --format ndjson < products.ndjson

Load time for 100,000 rows on NVMe: 94 seconds, including HNSW index construction with default M=16 and ef_construction=200. That works out to roughly 1,064 rows per second, embedding bytes included.

Run a query

Pick a vector to search with — in practice the embedding of a user’s query, here we just pulled one from a random row to keep the demo self-contained — and run nearest-neighbor search filtered by price:

SELECT id, title, price_cents,
       1 - (embedding <=> $1) AS similarity
FROM products
WHERE price_cents < 5000
ORDER BY embedding <=> $1
LIMIT 10;

Latency numbers, warm cache, single client, ef_search=64:

Operation	P50	P99
KV GET (small value)	0.4 ms	1.1 ms
Document point read by primary key	0.6 ms	1.4 ms
Vector top-10 over 100k rows, no filter	8 ms	18 ms
Vector top-10 with price_cents predicate	11 ms	24 ms
Single-row upsert (text + vector, one tx)	4 ms	9 ms
10 KB blob write + immediate read	6 ms	14 ms

None of these are competitive with a fat server. All of them are well inside what makes for a responsive demo, a homelab assistant, an on-device search UI, or a workshop you give to a room full of students who can each have their own Pi.

What this is and is not

This is portability proof. The same binary, the same protocol, the same SQL surface that runs on a c7g.8xlarge runs on $130 of hardware on your desk. There is no “lite” build, no missing modality, no separate config flag for “small mode.”

It is not a production deployment target for a real customer-facing system. The Pi’s single SSD is your single point of failure, the network is whatever’s in your house, and one CPU throttle event takes you offline. Treat it as a hobby rig, a dev environment, a teaching tool, an edge node where the alternative is no database at all.

What we like about this install is what it implies about every other install. If RedDB fits on a Pi, then the operator complexity of the four-engine stack we replaced — Postgres, Qdrant, Redis, S3, each with its own backups, auth, monitoring, version — was never inherent to the problem. It was the toll of the stitching.

The smallest sane install is one engine, one binary, one systemd unit. Everywhere else, you just need a bigger Pi.