Performance
What to expect on one node
| Operation | Typical |
|---|---|
A buffered write (conversation traces) | ~1.6 ms |
A confirmed write | 5–8 ms, mostly the disk sync |
| A batch of 20 writes | ~70 ms |
An indexed query (owner == $owner) at 10,000 records | ~8 ms |
| A warm query of 20 records | ~2 ms |
| Concurrent writers on one tenant | several hundred writes per second |
The accomplice's speed is dominated by the model, not by Mandala.
What helps
- A fast disk. Confirmed writes wait for
fsync. An NVMe SSD makes a visible difference; network disks are slowest. - The right model per workload. A fast model for triage and simple requests (Models and workload routing).
- Durability classes for high-volume, low-stakes contracts (Durability classes).
- Indexed filters first in queries, and paging by key (DHLQ query reference).
What not to do
- Don't run Mandala on a disk that lies about
fsync(some USB enclosures): a power cut could lose acknowledged writes. - Don't put the data directory on a network share.
Clusters
Certified writes across several voters cost several sequential durable rounds today (about 250 ms for a stock reservation on three local voters). A single-node Mandala is not affected. See Clusters.