HoloDb encodes every value as a phase vector and every row as a hologram, in a single associative store.
Because rows can be retrieved by resemblance as well as by key, one copy of the data answers three kinds of question —
exact SQL by primary key, similarity search by content with NEAREST, and analytics that read
maintained totals instead of scanning. No separate vector index, no OLAP cube, nothing to keep in sync.
SELECT SUM(amount_cents) — in-process, same query, same data, verified identicalHoloDb reads a maintained total rather than adding up 10 million rows: no scan, and response time holds constant as the ledger grows. Full per-query results follow — single-table rollups and cross-table joins, in-process against DuckDB and as a networked service against SQL Server.
dotnet add package EvaluatedApplications.HoloDbhow it works
Most databases store rows and bolt the rest on top — a separate analytical cube, a separate vector index — each kept in sync with the source of truth. HoloDb stores the source of truth as holograms.
Every value is encoded as a phase vector, and a row's columns are bound into one hologram; those holograms form a single associative store. Retrieval works by resemblance, not only by address — NEAREST (region='EU', status='overdue') returns the rows whose holograms are closest to a partial description, ranked by similarity: a vector query in SQL, over the same rows, with no separate index.
Aggregates fall out of the same algebra. An integer column's running total is a single vector — a residue-phase encoding read back in constant time — so SUM, COUNT and single-column GROUP BY read a maintained total rather than scanning, and hold their speed from one million rows to tens of millions.
Similarity uses a sublinear index above a few thousand rows. Integer sums are exact and constant-time; real-valued columns use a fast SIMD pass.
the shape of the data
Every number on this page comes from one realistic workload: a normalised invoices fact joined to a customers dimension — what a subscription business runs its dashboards on. 10 million invoices across 200,000 customers and 24 months of history — and the queries are the ones a billing dashboard actually fires: revenue by status, month and region; the running total; the biggest customers; a single-invoice lookup; and cross-table rollups by customer segment and signup cohort.
CREATE TABLE customers (
customer_id INT PRIMARY KEY, -- 200k customers
name TEXT,
segment TEXT, -- smb / mid / enterprise / strategic
tier TEXT, -- gold / silver / bronze
signup_month INT
);
CREATE TABLE invoices (
invoice_id INT PRIMARY KEY,
customer_id INT, -- FK → customers, ~50 invoices each
month INT, -- yyyymm, 202301 … 202412
region TEXT, -- US / EU / APAC / LATAM
status TEXT, -- paid / pending / overdue / refunded / failed
amount_cents INT -- money as integer minor units, never a float
);Money is stored as integer cents — the model Stripe and every accounting ledger use, and the reason HoloDb can keep revenue totals exact and constant-time.
the scoreboard
Two comparisons, each between like and like: the in-process, in-memory engines (HoloDb embedded and DuckDB), and the networked services (HoloDb's server and SQL Server). Identical billing queries — single-table rollups and cross-table JOINs — over identical data (10,000,000 invoices ⋈ 200,000 customers), loaded into each engine through its own bulk path. Every result is verified byte-for-byte identical across every engine before timing; figures are the median of many runs on 16 cores.
| billing query | HoloDb | DuckDB | faster |
|---|---|---|---|
| revenue by regionSELECT region, SUM(amount_cents) … GROUP BY region | 0.004 | 48.6 | HoloDb ~12,000× |
| invoices by statusSELECT status, COUNT(*), SUM(amount_cents) … GROUP BY status | 0.006 | 59.0 | HoloDb ~9,800× |
| total invoicedSELECT SUM(amount_cents) FROM invoices | 0.002 | 2.95 | HoloDb ~1,500× |
| invoice countSELECT COUNT(*) FROM invoices | 0.001 | 0.98 | HoloDb ~980× |
| revenue by monthSELECT month, SUM(amount_cents) … GROUP BY month | 0.011 | 7.11 | HoloDb ~650× |
| look up one invoiceSELECT … WHERE invoice_id = ? | 0.005 | 0.61 | HoloDb ~120× |
| big-ticket invoices (>$5k)SELECT COUNT(*) … WHERE amount_cents > 500000 | 6.40 | 3.85 | DuckDB ~1.7× |
| revenue by region & statusGROUP BY region, status (multi-column) | 129.7 | 76.8 | DuckDB ~1.7× |
| top customers by revenueGROUP BY customer_id … ORDER BY SUM(amount_cents) DESC LIMIT 10 | 321.7 | 162.0 | DuckDB ~2.0× |
| largest invoicesORDER BY amount_cents DESC LIMIT 20 | 11.8 | 4.48 | DuckDB ~2.6× |
| overdue outstandingSELECT SUM(amount_cents) … WHERE status = 'overdue' | 82.7 | 14.1 | DuckDB ~5.8× |
| revenue by segment (JOIN)invoices ⋈ customers GROUP BY customers.segment | 56.7 | 65.6 | HoloDb ~1.2× |
| revenue by segment & status (JOIN)⋈ customers GROUP BY customers.segment, invoices.status | 135 | 94.9 | DuckDB ~1.4× |
| enterprise revenue (JOIN)invoices ⋈ customers WHERE customers.segment = 'enterprise' | 34.3 | 10.3 | DuckDB ~3.3× |
| revenue by signup cohort (JOIN)⋈ customers GROUP BY customers.signup_month | 44.0 | 15.3 | DuckDB ~2.9× |
| top named customers (JOIN)invoices ⋈ customers … GROUP BY customers.name … LIMIT 10 | 808 | 322 | DuckDB ~2.5× |
The six rollups and the point lookup resolve from maintained accumulators and the primary-key index — no scan, hence microseconds, thousands of times faster, and flat as the ledger grows. On the single-table scans (a filtered sum, a top-K, a multi-column group) DuckDB's purpose-built columnar engine keeps a modest lead. The five cross-table JOINs now fan out in parallel across all cores: HoloDb wins revenue by segment and lands within ~1.4–3.3× of DuckDB on the rest — down from 15–92× before the joins were parallelised — all verified identical, and beats SQLite and (as a server) SQL Server outright. Bulk load, rows/sec: DuckDB 916k · HoloDb 359k.
| billing query | HoloDb server | SQL Server | faster |
|---|---|---|---|
| invoices by statusSELECT status, COUNT(*), SUM(amount_cents) … GROUP BY status | 0.124 | 4,032 | HoloDb ~32,000× |
| revenue by monthSELECT month, SUM(amount_cents) … GROUP BY month | 0.153 | 2,965 | HoloDb ~19,000× |
| revenue by regionSELECT region, SUM(amount_cents) … GROUP BY region | 0.134 | 2,575 | HoloDb ~19,000× |
| total invoicedSELECT SUM(amount_cents) FROM invoices | 0.129 | 1,156 | HoloDb ~9,000× |
| invoice countSELECT COUNT(*) FROM invoices | 0.138 | 589 | HoloDb ~4,300× |
| largest invoicesORDER BY amount_cents DESC LIMIT 20 | 7.42 | 3,001 | HoloDb ~405× |
| big-ticket invoices (>$5k)SELECT COUNT(*) … WHERE amount_cents > 500000 | 4.20 | 689 | HoloDb ~164× |
| revenue by region & statusGROUP BY region, status (multi-column) | 131.7 | 3,260 | HoloDb ~25× |
| overdue outstandingSELECT SUM(amount_cents) … WHERE status = 'overdue' | 83.2 | 1,004 | HoloDb ~12× |
| top customers by revenueGROUP BY customer_id … ORDER BY SUM(amount_cents) DESC LIMIT 10 | 285.8 | 3,277 | HoloDb ~11× |
| enterprise revenue (JOIN)invoices ⋈ customers WHERE customers.segment = 'enterprise' | 39.7 | 1,792 | HoloDb ~45× |
| revenue by segment & status (JOIN)⋈ customers GROUP BY customers.segment, invoices.status | 140 | 6,556 | HoloDb ~47× |
| revenue by segment (JOIN)invoices ⋈ customers GROUP BY customers.segment | 57.5 | 2,946 | HoloDb ~51× |
| revenue by signup cohort (JOIN)⋈ customers GROUP BY customers.signup_month | 67.6 | 2,853 | HoloDb ~42× |
| top named customers (JOIN)⋈ customers GROUP BY customers.name … LIMIT 10 | 806 | 4,173 | HoloDb ~5.2× |
| look up one invoiceSELECT … WHERE invoice_id = ? | 0.20 | 0.20 | tie (~0.2 ms) |
Both are networked services paying a client/server round-trip. HoloDb's server holds the working set in memory with the same maintained accumulators; SQL Server 2022 (LocalDB) reads its on-disk table. HoloDb leads on 15 of the 16 — every rollup and scan by 11× to 32,000×, and all five JOINs by 5× to 51× now that they fan out in parallel across all cores (the heaviest, the name-grouped join, lands at 806 ms against SQL Server's 4,173 ms) — conceding only the sub-millisecond point lookup. Bulk load, rows/sec: HoloDb server 697k · SQL Server 349k.
HoloDb is built for the mixed workload: a transactional ACID store, durable and larger-than-memory, that also resolves dashboard rollups in microseconds and runs vector search — in a single embeddable dependency. Full methodology & every number →
the Analyst
Any data — a CSV, a log, JSON lines — loads into a real HoloDb running entirely in the browser tab (compiled to WebAssembly, nothing leaves the device), which profiles it and opens a live SQL prompt. The same engine and the same speed as the benchmarks above, client-side.
capabilities
Relational rows, analytical rollups and a vector index are usually three separate systems kept in sync. Here they are three views of the same holographic store — one dotnet add package, one copy of the data.
Values are encoded as complex phase vectors, and a row's columns are bound into one hologram, so rows can be retrieved by resemblance, not just by key. The maintained totals are superpositions — sums of encodings — that a row is removed from by exact subtraction, which keeps UPDATE and DELETE exact. Holograms are derived from the columns, not stored per row, so there is no per-row space cost.
Real ACID: a reader/writer lock, pre-transaction snapshot rolled back on any error, fsync write-ahead log, and crash recovery bounded by live data, not write history. A substantial SQL dialect — joins, subqueries in IN, LIKE, BETWEEN, GROUP BY/HAVING, transactions.
One PRIMARY KEY per table (INT or TEXT). No OUTER joins or ALTER TABLE yet.
Retrieve by resemblance, not just by key: SELECT … FROM t NEAREST (col=val,…) LIMIT k ranks rows by similarity to a partial description — a vector query in SQL, over the same rows, with no separate index to build or keep in sync. A sublinear index takes over above ~8,000 rows in the in-memory engine.
NEAREST can't yet combine with WHERE/GROUP.
Because an integer total is itself one vector, whole-table COUNT/SUM/MIN/MAX and single-column GROUP BY read a maintained value in O(1) — no scan, flat as the table grows. Zone maps, compiled predicates and a columnar path keep ordinary filters fast.
Integer aggregates are exact + constant-time; real-number sums use a SIMD scan.
The paged engine stores tables on an 8 KB buffer-pool page store with a redo-only WAL: cold pages spill to disk, so a table can exceed RAM, with bounded crash recovery — and the size-independent aggregates are maintained on disk.
The primary-key index stays in RAM (~16 B/row) — the limit for tables far bigger than memory.
Whole-table and grouped counts/sums are served from an immutable snapshot republished after every write — without taking the engine lock — so a continuous streaming ingest never stalls a dashboard read.
deploy
var db = new HoloDbService(new HoloDbOptions { WalPath = "app.wal" });
db.Execute("CREATE TABLE t (id INT PRIMARY KEY, region TEXT, amount REAL)");
var r = await db.ExecuteAsync("SELECT region, SUM(amount) FROM t GROUP BY region");Sync or async, plus a column-native BulkLoad. Register with DI via AddHoloDb(), or attach to an EvalApp pipeline.
docker run -p 5432:5432 -v holodb-data:/data \
ghcr.io/evaluatedapplications/holodb:latest --token s3cretA self-hosted TLS server; the .NET client mirrors the embedded surface, so moving from in-process to networked changes only how the handle is obtained. Columnar results stay columnar on the wire.
The in-memory engine is pure managed .NET, so it compiles to WebAssembly and runs client-side — the Analyst tool is a real HoloDb in a browser tab, nothing leaving the device. Ideal for local/offline analytics and "your data stays with you" apps.
The Docker image is rebuilt from source and published as :latest (and :<version>) on every release, so :latest is always the current engine.
Add the package and go — every capability is free to use.
dotnet add package EvaluatedApplications.HoloDb