Measure performance

Measure the application you plan to deploy: its schema, restored data, access rules, hooks, relationships, locales, uploads, and admin extensions. A small framework fixture is useful for regression work, but it is not a capacity plan for another application.

Choose a representative workload

Include the operations that dominate real traffic and the largest documents authors actually edit. Warm up servers before timed samples, keep data and query shapes fixed between comparisons, and repeat trials in alternating order when comparing two implementations.

Use the repository performance gate

Ridu keeps focused Go, generated-project, browser, and comparison workloads under tests/performance/. From the repository root:

make performance-check

The gate reports behavior and measurements without turning desktop timing noise into a brittle unit test. For a focused CPU profile, compile the relevant benchmark once and pass Go’s -cpuprofile or -memprofile flag as described in tests/performance/README.md. Keep the Go version, operating system, CPU, garbage-collector settings, data size, and benchmark action identical for a before and after comparison.

Understand the current reference result

The 5 October 2026 reference run compared Ridu with Payload 3.87.0 on the same Apple M2 Max and local PostgreSQL 16.12 server. Runtime measurements are medians across three alternating trials:

The timed program performed selected-field lists and finds, authenticated versioned draft creates, updates and deletes, and admin HTML requests. It completed 43,200 timed requests without an unexpected status. PostgreSQL memory was excluded because both applications shared it.

Each application ran the way it is deployed. Ridu was a PostgreSQL-only build, like a generated PostgreSQL application, and both applications applied their migrations in a separate step before the timed server started. After seeding, both databases were analyzed, so the timings reflect steady-state query plans.

REST results

Latencies are p50 / p95 / p99 in milliseconds. The read payload sizes were not identical: median average response sizes were 3,377 bytes for Ridu lists versus 1,348 for Payload, and 333.93 bytes for Ridu finds versus 117.70 for Payload.

Draft creates omitted the optional unique slug, and updates changed the summary, so these timings do not measure contention between writes claiming the same unique key. Lists counted the whole published collection of 251 posts; at much larger sizes, the exact total count becomes the largest part of a list request unless the list passes pagination: false.

The environment was macOS 26.2 with 32 GiB RAM, Go 1.27.1, Bun 1.4.0, Node 24.13.0, Next.js 16.2.6, and PostgreSQL 16.12. Reads selected equivalent application fields and disabled Payload population. Writes used administrator accounts and exercised draft versions and trash deletion.

Admin response and artifact

Warm admin requests used concurrency 8. The program measured the Ridu binary and Payload standalone directory once, after all trials.

This measured the server response, not browser download, parsing, route chunks, rich-text startup, or interaction readiness. Ridu returned its embedded SPA entry with server-prepared admin data, including the schema manifest; Payload server-rendered its initial React document. The Payload standalone artifact also retained modules for the fixture’s SQLite fallback, so that artifact-size comparison is less controlled than RSS.

Block-heavy schemas

A block that several containers allow, inside containers that several layouts allow, appears at every path that nesting can reach. Those paths are its placements, and a modest block library can have hundreds of thousands of them. When a framework’s cost follows placements, memory and startup grow with the block graph even when every document is small. Ridu resolves, stores, types and binds each block definition once, so its cost follows the definitions you write.

The blocks fixture in tests/performance/blocks builds Ridu and Payload configurations from one framework-neutral spec per scenario, with the same fields, blocks, collections, drafts, access rules and relationships:

Each seeded document held 236–400 block instances (77–102 KB of JSON). The tables below use the references variant: blocks are declared once and selected by slug, with Payload’s blockReferences. An inline variant declares the same blocks inside each field. Both applications ran production builds against PostgreSQL 17.10 and a single-member MongoDB 8.2.9 replica set, in Docker on the same Apple M2 Max. Each combination ran three trials: reads at concurrency 8 and draft writes at concurrency 4, against 20 published documents.

Two details differ from the Payload reproduction on both sides. Slugs are kebab-case because Ridu requires them, and the reproduction’s Lexical rich-text field is a textarea.

Startup, memory and the admin

Medians across trials. “Admin edit” is the server response time for the first authenticated request to a seeded document’s edit page; it does not include browser rendering.

• Payload on PostgreSQL stays near 151 MiB idle in every scenario. Its admin edit response grows with the block graph.
• Payload on MongoDB grows with placements. Its adapter compiled 33,029 Mongoose schemas for B and 264,958 for C-over.
• Ridu stays within 29.6–35.2 MiB and 207–219 ms in every scenario. The admin edit response carried 181–213 KB for Ridu and 887–982 KB for Payload.
• Inline blocks: Ridu’s inline variant resolves to the same schema as references and idled at 29.6–40.7 MiB. Payload’s inline variant idled at 158–161 MiB on PostgreSQL and 693 MiB–1.30 GiB on MongoDB for A, B and C.

Requests

Successful requests per second, Ridu / Payload. “Find” reads one published document, and “List 10” returns the title and full block layout of ten. Draft creates and updates write a complete block-heavy layout. Neither side populated relationships.

p95 latency in milliseconds, Ridu / Payload:

Payload’s request loads were recorded for A, B and C only; its larger scenarios measured startup, memory and the admin. Ridu’s requests on A-full, B-dense and C-over matched its smaller scenarios: 1,322–1,509 finds and 120–138 draft updates per second on PostgreSQL, and 49–57 draft updates per second on MongoDB with p95 at most 89 ms.

Executable fields and GraphQL

A Ridu-only variant gives the first text field of every leaf block a beforeChange hook, a validator, a field access rule, a dynamic default and a visibility condition. Ridu binds those callbacks once per block definition:

• Memory and startup are unchanged: idle RSS is 29.9–35.1 MiB and startup 206–213 ms.
• Writes run the callbacks at every block instance: draft creates and updates handled 6–33% fewer requests per second than without them. On PostgreSQL, that was 121–147 creates and 87–106 updates per second; on MongoDB, 64–73 creates and 43–49 updates per second.

With GraphQL enabled on scenario A over PostgreSQL:

• Ridu built its GraphQL schema at startup without slowing it (206 ms, against 208 ms without GraphQL), idled at 33.4 MiB and answered the first query in 6.4 ms.
• Payload idled at 151.6 MiB, answered the first query in 76.3 ms and held 212.3 MiB afterwards.

Payload 3.87.0 (Next.js 16.2.6, Mongoose 8.22.1) was recorded on 5 October 2026. Ridu was recorded on 6 October 2026. Both runs used the same host, Go 1.27.1, Bun 1.4.0, Node 24.13.0 and Docker images. Payload was not rerun because its code had not changed between the runs.

Report limits with the result

State the data size, concurrency, trial count, hardware, software versions, topology, query shape, success criteria, and known asymmetries. Keep cumulative B/op separate from peak RSS. Keep server HTML timing separate from browser interaction time. Do not call a result faster if one side timed out or returned less work without reporting it.

The reference fixture did not cover upload/image throughput, very large databases, every access or localization shape, a hardware matrix, or complete browser interaction timing. The blocks fixture seeded 20 documents per scenario and replaced rich text with a textarea, so it measures schema cost rather than large collections or rich-text editing. Use it to reproduce the method, then replace its schema and traffic with your own before choosing instance sizes or setting an SLO.