Reports fresh in 0.30 s under a 10,000-write storm — on a million rows. Measured.
Database marketing runs on adjectives. This page runs on numbers: a reproducible benchmark of the GF Cloud DB — the data layer of the GritFlow Framework — across five categories, every result traceable to a scenario you can re-run.
Engine benchmarks measure synthetic queries per second. None of them answer the questions that actually decide whether an app can trust its data layer: How fast are reports after heavy writes? Does speed hold as the data grows? Can a change ever be lost? And can anyone — human or AI — understand the schema afterward?
Those are the five categories below. Database vendors are invited to run them and submit results — the harness and the raw outputs are available on request.
How fast are reports — even under heavy writes?
| Reporting rollup, first build | 0.04 s | MEASURED |
| Report refresh after a 10,000-write storm (100K rows) | 0.05 s — only the 5 touched buckets recompute | MEASURED |
| Report refresh after a 10,000-write storm (1M rows) | 0.30 s — no warehouse, no ETL, no nightly job | MEASURED |
| Bulk load rate | 1,408,552 rows/s | MEASURED |
| Live insert rate, fully tracked | 175,831 rows/s | MEASURED |
How long from an existing database to fully managed?
| 100,000-row database | Ready in 0.6s | MEASURED |
| 1,000,000-row database | Ready in 5.5s | MEASURED |
| 3,000,000-row database | Ready in 16.7s | MEASURED |
| Hand-written config, schema edits, or migrations required | None — one call against the existing database | ZERO |
Can any write, anywhere, ever be lost?
| Same row edited on both sides at once | Deterministic winner; the losing version preserved and restored live | PASS |
| Process killed mid-sync | Atomic rollback of the whole transfer; re-run completes it, idempotent after | PASS |
| Offline catch-up (500 + 200 changes apart) | Exactly 40 conflicts detected — every one recoverable | PASS |
| 1,500 random ops fuzzed across both nodes | Full-table parity at the end | PASS |
| 2,000 writes on 4 threads during 7 concurrent syncs | Zero lost rows, zero duplicates, in 4.1s | PASS |
| Mismatched schema versions (v2 talking to v1) | Stays tolerant; converges after migration | PASS |
How much actually crosses the wire?
| 10,000 changed rows in a 1M-row database | 128 KB gzipped vs the 68 MB database — 531× smaller | MEASURED |
| 10,000 changed rows in a 3M-row database | 143 KB gzipped vs the 207 MB database — 1,448× smaller | MEASURED |
| One live update between two real processes over HTTP | 0.5 KB total on the wire | MEASURED |
| Steady-state overhead | ~42 bytes per row — you'll never notice it | MEASURED |
After onboarding, how much of the schema explains itself?
| Northwind exemplar (13 tables, 16 views) | 100% of the schema carries machine-readable intent | MEASURED |
| Full AI-ready context for the whole database | ~4.8K tokens — every table, column, and relationship explained | MEASURED |
| Compact digest tier | ~400 tokens — fits any AI session, always current | MEASURED |
Sub-second at every scale measured — only the touched buckets recompute.
Every number on this page comes from one proof run: 152 scenario checks across 14 narrated real-use-case scenarios, 205 regression checks, and a load/chaos/fuzz suite — one command, one verdict, all green on 2026-07-03.
Environment: a single developer workstation · row shape ≈ 90 bytes/row · scales measured at 100K, 1M, and 3M rows. Test artifacts are deleted after each measurement; nothing is cherry-picked from prior runs.
Scenarios cover real usage, not synthetic queries: reports refreshed under live write storms, two live databases both accepting writes, offline sessions catching up, processes killed mid-sync, concurrent writers during active syncs, mismatched schema versions, and 1,500-operation random fuzzing — each ending in a byte-level parity check.
ElectricSQL and PowerSync solve adjacent problems well — see how the categories compare.
| Baseline build rate | 1,408,552 rows/s |
| Enroll + backfill (100K rows) | 0.6 s |
| Live insert rate, fully tracked | 175,831 rows/s |
| 10K-row delta compute | 0.07 s |
| Delta RAM peak | 8 MB |
| Payload, 10K rows (gzipped) | 126 KB (53× smaller than the database) |
| Sync 10K rows end-to-end | 0.17 s · 57,610 rows/s |
| Reporting rollup, first build | 0.04 s |
| Report refresh after a 10K-write storm | 0.05 s (5 buckets touched) |
| Storm refresh at 1M rows | 0.30 s |
The full harness — all 14 scenarios, the regression suite, and the load/stress runner — is available to engineering teams on request. Every number above carries its scenario ID so you can re-run exactly what we measured.
Request the HarnessA reporting rollup builds in 0.04 seconds. After a 10,000-write storm it refreshes in 0.05 seconds on a 100K-row database — only the touched buckets recompute — and in 0.30 seconds on a million-row database. There is no warehouse, no ETL pipeline, and no nightly job behind those numbers; the GF Cloud DB keeps its own reports fresh.
The benchmark measures the same operations at 100K, 1M, and 3M rows. Onboarding takes 0.6s, 5.5s, and 16.7s. A 10,000-row update payload stays nearly flat: 126 KB, 128 KB, and 143 KB gzipped. Report refresh after a 10,000-write storm is 0.30s at a million rows. Every number is in the results tables above with its scenario ID.
The conflict resolves deterministically — the production side wins — and the losing version is preserved and restorable, verified live in the benchmark. No silent overwrites: an offline session that came back with 200 changes against 500 on the other side produced exactly 40 conflicts, every one recoverable.
No. The GF Cloud DB is the source of truth and the reporting layer at once — reporting rollups rebuild themselves as data changes, measured at 0.30s under a 10,000-write storm on a million rows. There is no second system to run, no pipeline to babysit, and no sync job to a warehouse.
The GF Cloud DB is part of the GritFlow Framework — the data layer that keeps its own reports fast, documents itself, and never loses a change, so your team just builds.
