Benchmarks¶

This page collects the current Python embedded comparison charts and a plain-language summary of where DecentDB is leading or trailing in the pack.

Benchmark snapshot metadata¶

• Document updated: 2026-03-25 18:28:28 UTC
• Ranking snapshot: final sweep point at 500 operations from the exported benchmark bundles in docs/assets/benchmarks/python-embedded-compare/

Engine version stamps¶

Overview¶

These benchmark results come from the Python embedded comparison harness in benchmarks/python_embedded_compare/. The goal of that harness is not to produce a single marketing number, but to compare DecentDB against other embedded engines across a small set of repeatable workloads using the same orchestrator, dataset shape, and measurement flow.

What this benchmark is measuring:

• Embedded database behavior under the same Python-driven benchmark runner
• Mean latency across a sweep of operation counts
• Read-heavy and write-heavy query shapes, not just one microbenchmark
• Relative standing of DecentDB versus a mixed pack of native and JVM-backed embedded engines

Database engines included on this page:

• DecentDB
• SQLite (SQLite_wal_full configuration)
• DuckDB
• H2 (JDBC)
• Apache Derby (JDBC)
• HSQLDB (JDBC)

Workloads covered here:

• workload_c: a flat-table benchmark focused on indexed point lookups and full scans, intended to mirror the simpler Python binding access pattern more closely
• workload_a: an OLTP-ish orders-and-customers workload covering point selects, range scans, joins, aggregates, updates, and deletes

How to interpret the results:

• Lower mean latency is better.
• The summary table at the top uses the final sweep point shown in the charts: 500 operations.
• The charts underneath show the full trend across 10, 50, 100, 250, and 500 operations.
• A strong result on one benchmark does not imply the same result on all benchmarks; this page is meant to show both the strong and weak areas clearly.

The summary table below uses the latest sweep point shown in the charts: 500 operations. Lower mean latency is better.

At-a-glance summary¶

Notes:

• 0.00 us/op means the chart data rounded the measured mean latency down to zero at this display precision. It does not mean the operation was literally free.
• 6th of 6 on a chart means DecentDB was slowest for that specific benchmark at that specific operation count. It is not an overall ranking across all benchmarks.
• These charts come from the exported benchmark bundles in docs/assets/benchmarks/python-embedded-compare/.

How to read these charts¶

Use this page in two passes:

1. Check the summary table first. It tells you where DecentDB ranks at the 500-operation sweep point for each benchmark.
2. Then look at the matching chart to see the full curve across 10, 50, 100, 250, and 500 operations.

Reading rules:

• Lower mean latency is better.
• The dark DecentDB series is emphasized so you can find it quickly.
• The badge on each per-benchmark chart reports DecentDB's rank for that benchmark at the final sweep point.
• A rank like 2nd of 6 means only one engine was faster on that metric at 500 ops.
• A rank like 6th of 6 means DecentDB was slowest on that benchmark at 500 ops, not that it was worst overall.

Example:

• In workload_c / full_scan, DecentDB is 1st of 6, so it leads that benchmark at 500 ops.
• In workload_a / update, DecentDB is 5th of 6, so it trails the pack on that specific write-path measurement.
• In workload_a / point_select, DecentDB is 2nd of 6, which is a competitive result even though it is not the leader.

Workload C: Flat-table binding parity¶

This workload mirrors the simpler Python binding access pattern more closely than the OLTP-style canonical suite.

Overview¶

Point select¶

Full scan¶

Workload A: OLTP-ish orders¶

This workload uses the canonical orders-and-customers schema and is more sensitive to write-path and relational execution behavior than workload C.

Overview¶

Point select¶

Range scan¶

Join¶

Aggregate¶

Update¶

Delete¶