SlateDB with its default 100 ms flush interval took 82.8 times as long as Flyology.DB for one 1 KiB value.
Directional evidence · 30 August 2026
Commit latency depends on the workload.
Flyology.DB had lower median primary latency in selected small durable transactions. TidesDB or SlateDB had lower latency in larger batch and sustained workloads. Explore all 41 paired comparisons before drawing a conclusion.
Retained campaign
41 comparisons. Every participant reopens and verifies the expected state.
Each pair has 10 samples and balanced 5/5 execution order. Before each pair, flyology_bench applied its CPU admission gate. After timing, each participant closed, reopened, read every expected key-value entry, and compared the bytes. The artifacts retain aggregate statistics, not individual timing samples.
Flyology.DB Ada transactional database
SlateDB Rust object-storage engine
TidesDB C transactional storage engine
RustFS shared S3-compatible server
What the data says
Results change with the workload.
Lower median primary latency is better. The primary timer covers begin, every put, and durable completion.
Flyology.DB took 4.1 times as long as TidesDB for one transaction with 256 mutations.
Flyology.DB took 23.7 times as long as SlateDB with a 1 ms interval across 8,960 key-value writes.
Interpretation: the results are consistent with fixed per-transaction costs affecting small commits and with batching amortizing those costs. The campaign does not identify where the costs occur.
Interactive evidence
Change one dimension at a time.
The primary timer covers begin, every put, and durable completion. It excludes setup, close, reopen, and verification. The ratio is contender median divided by Flyology.DB median. Above 1× means Flyology.DB has lower median primary latency.
Pairwise time ratio
Logarithmic scale. The 1× line is equal time.
Below 1×: contender has lower timeAbove 1×: Flyology.DB has lower time
Loading retained benchmark data…
| Workload | Contender | Flyology.DB time | Contender time | Pairwise result | 95% contender-time change vs Flyology.DB | Evidence |
|---|
Medians summarize 10 paired samples. The artifacts retain aggregate statistics, 5/5 order counts, bootstrap intervals, host fields, requests, and content hashes. They do not retain individual timing values or order vectors.
Claim boundary
Separate observations, possible causes, and unmeasured behavior.
This section states what the campaign established and what it did not measure.
Flyology.DB had lower median latency in selected small-commit comparisons.
After each measured workload, each adapter closed and reopened its database and read every expected key-value entry.
The results are consistent with fixed per-transaction costs.
The Flyology.DB advantage falls as each transaction carries more mutations. The campaign did not profile internal work.
The campaign does not measure production workloads.
It does not test concurrency, tail latency, CPU, memory, real networks, failure injection, or power loss.
Limits
What these comparisons do not establish.
Read these limits together. Each one narrows the claims on this page.
- One writer uses generated keys and values in a fresh database for every sample.
- The measured workload contains no reads, scans, concurrent clients, or accumulated maintenance backlog.
- The RustFS lane uses loopback networking, not a production network.
- The CPU admission gate runs before sampling. It does not measure I/O, thermal, frequency, interrupt, or mid-sample interference.
- Each pair retains aggregate statistics from 10 samples. It does not retain individual timing observations.
- Close and reopen verify bytes after normal execution. The campaign does not inject a crash or power loss.
Participants
What each engine actually is.
Flyology Object Storage and RustFS are infrastructure. They are not extra database competitors.
- Flyology.DB
- An experimental embedded transactional key-value database for Ada. It owns transactions, column families, the global commit sequence, checkpoints, and conditional publication. Local tests use Flyology Object Storage Files. Remote tests use its S3-compatible provider.
- SlateDB
- An embedded Rust storage engine designed for object storage. Its group-commit flush interval is 100 ms by default. The panel keeps that default and adds a separate 1 ms sensitivity variant. Neither variant is presented as a universal optimum.
- TidesDB
- An embedded C key-value engine with transactions, column families, a write-ahead log, and an LSM tree. The local lane requests full write-ahead-log synchronization. The remote lane excludes its pinned S3 path because that path does not preserve the same upload-failure contract.
- Flyology Object Storage
- The provider library under Flyology.DB. It supplies Files and S3-compatible object operations. Flyology.DB retains transaction, publication, and recovery policy.
- RustFS
- The pinned S3-compatible server used for the remote lane. Eligible participants used the same loopback server and isolated key namespaces.
Method
The primary timer excludes setup and verification.
The benchmark measures transaction work, not process launch. All three engine adapters execute inside the benchmark process. SlateDB crosses a narrow Rust C ABI. Flyology.DB and TidesDB use direct Ada bindings.
- Pass the CPU admission gateBefore each pair,
flyology_benchrequires two continuous seconds at or below 25% average CPU and 60% on the busiest logical CPU. - Interleave each pairTen samples use deterministic balanced order: five start with Flyology.DB and five start with the contender.
- Measure durable workThe primary timer covers begin, every put, and the participant's durable completion. Setup and verification stay outside.
- Reopen and verifyEach adapter closes, reopens, and compares every expected key and value byte-for-byte.
- Seal immediatelyEach pair retains its request, comparison JSON, metrics NDJSON, content hashes, and hashed campaign identity.
Workloads
Keys, values, batches, and sustained writes.
Every point uses a fresh database and one warm-up transaction. The workload then varies one reviewed dimension.
Key size
8, 16, 64, and 256-byte keys with 1 KiB values and one mutation per transaction.
Value size
64 B, 1 KiB, 16 KiB, and 64 KiB values with 16-byte keys and one mutation per transaction.
Batch size
1, 16, 64, and 256 mutations in one transaction. Every key is unique.
Sustained writes
35 transactions of 256 mutations: 8,960 key-value writes. The final reopen verifies the complete state.
Power-profile disclosure
The operator reported selecting macOS High Power while connected to AC. Both campaign artifacts record the detector result low-power. Because these records conflict, treat the host power mode as unknown.
Reproduce
Download and reproduce the retained campaigns.
First follow the benchmark build and dependency prerequisites. Each command below creates an absent scratch output. Resume mode is only for an incomplete sealed campaign.
Local campaign command
benchmark_root=$(mktemp -d)
python3 benchmarks/comparison/run_realistic_campaign.py \
--lane local \
--output "$benchmark_root/local.json"RustFS campaign command
benchmark_root=$(mktemp -d)
FLYOLOGY_DB_BENCHMARK_OUTPUT="$benchmark_root/rustfs.json" \
FLYOLOGY_S3_SERVER_RUNNER="$PWD/benchmarks/comparison/run_realistic_rustfs.py" \
./.deps/flyology-object-storage/tests/scripts/test-rustfs.sh- Local aggregate
publishable-local.jsonloading…- RustFS aggregate
publishable-rustfs-v2.jsonloading…- Local collection snapshot
loading…- RustFS collection snapshot
loading…- RustFS image
ghcr.io/rustfs/rustfs@sha256:800cf3f352a0a27e3275ca854a51f0027975d7acc7a0d52089a35bcc9fcbf0b5- Sampling
- 10 paired samples, balanced 5/5 order, 2,000 paired bootstrap resamples, 95% interval
Current harness source
Inspect each durable transaction implementation.
These excerpts show the current reviewed adapter code, not the exact historical bytes used by both retained campaigns. The campaign artifacts retain their collection-time source and executable hashes. If a marker is absent, duplicated, or outside the repository, the build fails.
Flyology.DB · Ada
Loading source identity…
Loading exact source…TidesDB · Ada and C ABI
Loading source identity…
Loading exact source…SlateDB · Rust C ABI
Loading source identity…
Loading exact source…Read the complete benchmark implementationReview product boundaries