Embedded HTAP: operational writes and analytical scans together

What embedded HTAP means

OLTP paths favor small writes, point reads, constraints, and short transactions. OLAP paths favor projection, compression, vectorized execution, and scans across many rows. An embedded mixed-workload engine needs both without copying every committed change into another local store.

“HTAP” is a useful shorthand, but deployment scope matters. MongrelDB's primary production profile is embedded or single-node server operation. That is different from a distributed HTAP platform promising independent compute pools and global failover.

One practical architecture

1. WAL first: accepted changes enter an append-only write-ahead log; durable commit includes fsync.
2. Mutable write layer: a Bε-tree memtable stores new row versions by RowId and epoch.
3. Immutable columnar runs: flush creates PAX-style .sr runs with adaptive per-column encoding.
4. MVCC reads: readers pin snapshots while writers continue committing newer epochs.
5. Predicate and projection pushdown: indexes and page statistics avoid decoding rows and columns that cannot match.
6. Analytical SQL: DataFusion executes joins, recursive CTEs, window functions, materialized views, and aggregations.

This keeps fresh writes and scans on one recovery path. It also means both workloads compete for the same CPU, memory, storage bandwidth, and process lifetime.

One engine versus two

Use measurements, not labels

MongrelDB publishes reproducible local measurements. On its documented July 2026 release-build machine, one million typed rows loaded in 58.471 milliseconds, a typed full scan took 83.707 milliseconds, Bitmap equality took 8.0387 milliseconds, and durable single-row commit measured 4.6721 milliseconds.

These values come from one Linux x86-64 machine and are not service-level guarantees. More importantly, the mixed-load qualification shows that concurrent readers change write latency: four writers and four readers at one-million-row scale recorded a 33.012 millisecond commit p50 and 176.885 millisecond p99 under that test shape.

Good embedded HTAP workloads

• Desktop applications with operational edits and local dashboards.
• Edge jobs that ingest events and aggregate without network access.
• Developer tools storing activity and querying trends in one product.
• Agent and RAG applications combining state, metadata, and retrieval.
• Test harnesses needing transactions and analytical assertions.

Use separate systems when

• analytical queries must never contend with customer transactions;
• storage or compute exceeds one node;
• independent retention, governance, or teams own each workload;
• the warehouse must join data from many operational systems.

Evaluation plan

1. Capture a representative write rate and transaction size.
2. Run the largest analytical query while writes continue.
3. Measure p50 and p99 commit latency, not only scan throughput.
4. Set query deadlines, memory limits, and spill ceilings.
5. Test cancellation, restart recovery, backup, and point-in-time restore.
6. Split the systems only when measurements show the shared boundary is the problem.