Performance / reproducible local evidence

Show the speed.
Show the work.

A real million-product database. Bounded reads, validated prices and durable orders through Rust and PostgreSQL. Fixed arrivals include client queue time.

The million-product measurement

At 500 offered requests/s, each read workload runs for approximately 4 seconds; checkout for 2 seconds. p50, p95 and p99 include scheduling, client queue, new HTTP connections, the full response and validation. The achieved rate follows the offered rate; this is a short probe, not maximum capacity. No response cache bypasses PostgreSQL.

Apple M3 Ultra, 512 GiB host RAM; Docker engine limited to about 7.65 GiB and 24 CPUs. PostgreSQL 17 uses warm caches, fsync and synchronous commit enabled. Rust release build; Python client shares the host. A pure HTTP process and an independent outbox worker are active. Checkout changes stock and commits an order; payment is simulated.

The 100 requests/s control

The same final build also ran 1,000 requests per read workload and 500 fresh checkouts at fixed arrivals of 100/s: 6,500 measured requests, zero errors, 516 unique persisted orders including warm-up. These longer 10-second reads provide the matched follow-up to the failed cart run below.

Download the complete 100/s control ↗

The failed cart run — and the fix

The first million-product run achieved only 34.9 cart reads/s at an offered 100/s. Its client admission guard rejected 634 of 1,000 scheduled reads; successful cart reads had p95 645.3 ms. PostgreSQL scanned the entire tenant for an OR/subquery. Direct indexed SKU and parent lookups removed that scan. The identical workload was then rerun: cart p95 fell to 14.7 ms with zero errors. Both tables above contain the final build.

Inspect the failed run and all client rejection records ↗

The earlier full-catalog comparison

The historical comparison below returned all 1,000 products in one response and used closed-loop clients. The current API returns at most 100 (default 50), so its smaller response is not a like-for-like full-catalog speedup. The original results and diagnostics remain available.

Historical results: all workloads

Each cell is the median of three rounds. p95 is the 95th-percentile duration inside a round, including the complete HTTP response and JSON validation. Throughput counts successful requests per elapsed second. “Clients” means concurrent closed-loop clients.

What changed in the core

• Indexed translations: one lookup map replaces repeated scans of every translation. Language fallback remains field-specific; NULL and an explicitly empty string keep their different meanings.
• One product per preview: a catalog price preview searches its actual product, rather than searching the entire catalog once for every product.
• Cart-sized loading: a cart loads its own SKUs and their parents. A 20-line cart no longer hydrates 1,000 unrelated products and translations.
• Complete request intake: the catalog HTTP handler reads the POST body before returning a large response. Separate diagnostic runs exposed truncated responses when the body was left unread.

The measurement conditions

Hardware

Apple M3 Ultra · 512 GiB host RAM. This is a powerful development workstation.

Software

macOS · cargo release build with thin LTO · PostgreSQL 17 in Docker, using the project's AGE + pgvector image.

Fixtures

Two isolated synthetic shops: 6 and 1,000 root products. All products have German translations, identical €24.90 gross prices and ample stock. The cart contains 20 distinct items.

Transport & client

Local HTTP/1.1, a fresh connection per request, Python threads on the same host. Catalog measurement uses POST with no body, identically before and after. The client reads and validates every response; its overhead and shared-host contention are included.

Warm-up

One validated request per client before each round. Database and operating-system caches are warm; this is not a cold-start measurement.

Checkout

Every measured checkout has a fresh cart and unique idempotency key. Stock is updated and the order is committed in PostgreSQL. Payment is simulated; no payment-provider network request is timed. All measured order IDs are checked directly in the database.

Failed attempts are part of the record

Initial catalog runs sending a JSON POST body timed out or received connection resets. They were aborted, not counted as clean benchmark runs. Body-free control requests completed; the HTTP body-consumption fix was then tested with the original JSON-body case. Read the diagnostic record and follow-up result.

Run it yourself

The reproducible setup documents the isolated database, build commands and benchmark script. Raw files include every successful latency, failures, source revision/diff and binary hashes.

What these numbers do not establish

Production capacity, internet latency, cold-cache performance, a many-shop fleet, distributed deployment, real payment-provider performance and local LLM generation speed remain unmeasured here. There is no Shopware speed comparison. These are bounded local measurements, not a production SLA or maximum server capacity.

Watch the short feature clips →