What can this
database really do?

A useful local alpha.
Its limits are now measurable.

All executed correctness checks passed; capacity refusals below remain findings.

At 4,096 base records, RURAL point-read p95 was 1.198 ms and filtered/sorted-page p95 was 28.632 ms. The corresponding SurrealDB observations were 2.387 ms and 2.114 ms. These are specific local API paths on this machine, not a universal database ranking.

Latency, with the costs visible.

Median of per-trial p95 values. Each workload's bar scale is independent; compare engines within one workload. Smaller is better. HTTP includes serialization, loopback, authentication and response validation; SQLite executes in-process.

On narrow screens, scroll the chart horizontally to see every value. Exact values also appear in the searchable ledger.

HTTP traffic is capped at 200 requests/s to protect temporary TCP ports. Operation latency excludes explicitly recorded pacing sleep; achieved throughput includes it. These rates are not maximum engine capacity. Both active and wall samples are retained in the raw JSON.

Batch charts report latency per transaction, not per document. The ledger reports logical documents/s for batched writes. A/B/C/F mixes are inspired by YCSB, with deterministic uniform keys; these are not certified YCSB or TPC scores.

Writes arrive. Readers keep working.

One writer submits 64-event batches while two readers each target 20 queries/s. Every accepted event is checked by exact analytics and again after restart. The short schedule exposes contention and lateness; it does not establish sustained capacity or global delivery guarantees.

Entries are medians across trials, except total accepted. Scheduled latency starts at the intended arrival time, so accumulated backlog is visible. A delayed batch remains counted; there are no automatic retries. Limits remain 20,000 raw events and a 64 MiB journal in the current service profile.

Speed only counts when the answer survives.

RURAL profiles also contain branch history, graph records, event facts and receipts. Other profiles contain the shared CRUD workload only. Compression, auxiliary data and retained history differ, so profile sizes are not a storage-efficiency ranking. Reopen timings include different lifecycle work for embedded and server engines.

Choose by workload, not by a single winner.

Architectural assessment below; only the explicitly measured adapters have timing results in this report.

Engineering priorities suggested by these observations

1. Bound the sorted-query candidate path, with a regression for the observed callback-budget refusal.
2. Add measurable indexing/query-plan visibility before positioning RURAL as a warehouse.
3. Run longer intake/reader/analytics schedules with overload, drain, backup and native frame telemetry; keep P26 separate.
4. Measure end-to-end Oracle quality and actual model-reported tokens before making AI-cost claims.
5. Qualify durable compaction, backups, restores and large histories before raising the service's caps.

The complete measurement ledger.

Rejected operations are excluded from successful latency/throughput. Single-sample fork cases and eight-transaction batch cases are descriptive observations, not stable tail estimates. Raw p99 values are retained in JSON with an insufficient-sample flag; no stable p99 claim is made here. Base records identify the stage; payload and specialty probes add records afterward.

A bounded, versioned experiment.

Peak aggregate CPU sample: 96.3% (100% is one logical core). Peak scratch files: 43.7 MiB. CPU/RSS/disk ceilings are sampled stop thresholds; they reserve no hardware and can briefly overshoot. Tests run on a shared machine with warm OS caches and lower scheduling priority. They are not clean-lab maximum-throughput or hardware failure tests.

RURAL binary SHA-256: 46cf9b51a60b6ab12eaff7355b4fc4a5aa53d63f6c1cfe1418df7901d0586cf4. SQLite: 3.53.4. SurrealDB: 3.2.4+20260803.93ab219 for macos on aarch64. The source commit is 2b4c49e56ac21c6ca3876d44b992b47c779e0805; the JSON also binds each harness source file.

RURAL and SurrealDB use one fresh HTTP connection per operation and bearer authentication. SQLite uses WAL + synchronous FULL, an 8 MiB cache and no secondary field index. SurrealDB uses RocksDB with explicitly requested synchronous commits, background flush disabled, one storage background thread and two Tokio workers. RURAL writes include domain validation and durable replay receipts. These contracts are not identical; the report compares observed application paths.

{
  "config": {
    "suite": "rural-bench/1",
    "results": "rural-bench-results/1",
    "adapter": "rural-http/1",
    "protocol": "rural.prototype/1",
    "seed": 2077,
    "budget": {
      "rss_mib": 768,
      "disk_mib": 256,
      "wall_seconds": 900,
      "process_cpu_seconds": 180,
      "sustained_cpu_percent": 200,
      "clients": 3
    },
    "scales": [
      256,
      1024,
      4096
    ],
    "trials": 3,
    "samples": 120,
    "payload_bytes": 512,
    "notes": "Synthetic local service observations; YCSB-inspired A/B/C/F, not a conformant YCSB or TPC result. Version this contract when workload semantics change."
  },
  "host": {
    "system": "macOS-26.6.2-arm64-arm-64bit-Mach-O",
    "machine": "arm64",
    "cpus": 8,
    "python": "3.14.6"
  }
}

Primary methodological references

• YCSB workload definitions
• pgbench: rate, schedule lag and latency
• SQLite synchronous durability modes
• SurrealDB server configuration
• SurrealDB durability and resource settings
• PostgreSQL MVCC
• MongoDB sharding
• TigerBeetle pending, post and void transfers