Materialized View API Serving Benchmark

Detailed methodology and results

Supporting methodology, figures, and tables are rendered here as native page content with the same visual system as the rest of this website.

API-level benchmark using denormalized benchmark tables that mirror the REST API response shapes. Results were generated from the new 100k, 1m, and 10m runs saved in the benchmark result JSON.

Executive Readout

RDS remains the faster serving path for this API shape. At 10m rows, sequential RDS p50 latency stayed between 0.91ms and 14.40ms across the eight endpoints. StarRocks async MVs stayed between 13.40ms and 175ms .

The slowest relative 10m sequential endpoint was Content items, high-velocity tab, 50 rows , where StarRocks MV p50 was 18.19x RDS p50. Under 100-way concurrency, the category/country/language endpoint was the biggest gap: RDS p50 168ms versus StarRocks MV p50 2.21s .

Recommendation:

What Was Compared

RDS Path

• Temporary denormalized PostgreSQL tables for snapshot, filters, and result cards.
• B-tree indexes for sorted/filtered lookup paths plus GIN indexes for array/search fields.
• API call executed through the benchmark HTTP service against RDS.

StarRocks MV Path

• Iceberg base tables in AWS S3 Tables.
• StarRocks asynchronous materialized views with REFRESH DEFERRED MANUAL .
• Separate sorted content MVs for rank, activity/day, velocity, views, and published-at API sorts.
• API call executed through the same benchmark HTTP service against StarRocks MVs.

Fairness check:

Payload Parity

Sequential p50 Latency by Scale

These are single-client API calls after warmups. Ratios show StarRocks MV p50 divided by RDS p50.

10m Concurrency Results

Concurrency levels were sequential, 5, 25, and 100. For concurrent runs, each worker issued 5 requests.

Setup And Refresh Costs

Setup timings are not request latency, but they matter operationally because the proposed path needs data load and MV refresh before API reads.

Materialized View Refresh Detail

Important StarRocks / S3 Tables Finding

Repeated appends into the same AWS S3 Tables Iceberg table failed from StarRocks with PreconditionFailed errors after the first append. This reproduced in a targeted StarRocks-only 2m test: the first 1m insert committed, the second 1m append failed after retries.

A single large insert did work. The successful 10m run loaded the content base table as one insert and used these StarRocks session settings:

• SET enable_adaptive_sink_dop = false
• SET pipeline_sink_dop = 1
• SET pipeline_dop = 1
• SET max_pipeline_dop = 1
• SET parallel_fragment_exec_instance_num = 1

Implication:

Interpretation

• For low-latency REST reads, RDS is still the stronger fit in this benchmark. It stays in the low single-digit millisecond range for the indexed 50-row endpoints at 10m rows.
• StarRocks MV latency is more stable than direct Iceberg querying, but it still has a baseline tens-of-milliseconds cost and degrades sharply on the category/country/language case at 10m rows.
• The denormalized model is appropriate for this API comparison. Because the tables are intended to be direct API equivalents, the payload parity checks are the right correctness gate.
• The next useful work is not another synthetic scale alone. The next report should add production-like filter cardinality, distribution skew, refresh frequency, cold/warm cache separation, and API service overhead from the actual application code path.

Benchmark Provenance

• Benchmark result JSON retained as local source data
• Native report page generated from the local benchmark notes
• Temporary AWS resources were removed after the run: S3 Tables benchmark tables, StarRocks secret, IAM inline policy, and runner temp files.