Following the decision to remove real-time collaboration from WordPress 7.0, this post summarizes what the latest hosting test data showed and outlines the recommended storage strategy for future iteration. A huge thank you to every web host that submitted results in response to last week’s call for testing. Submissions came in from eight hosting environments between April 29 and May 4, and analysis of the aggregated, anonymized data is now complete. Based on the results, the recommendation is to use custom-table-with-transients as the default RTC storage strategy for continued testing and future iteration.
As a reminder, four candidate storage strategies for the Real Time Collaboration (“RTC”) feature were tested under load:
post-meta — the RC2 baseline.
custom-table — a dedicated table for all RTC data.
post-meta-transients — post meta for storage with transients for client awareness.
custom-table-with-transients — a dedicated table with an object cache-backed awareness (Note: while contributors have been referring to this as a transient approach, it is a convenient short hand rather than a technical description)
The test runner captured per-request REST dispatch time and database query counts during sustained 30-second polling windows. Eight complete captures from a mix of shared, shared-with-Redis, managed-cloud, and no-object-cache environments form the basis of the analysis below.
Across the cohort, custom-table-with-transients was first or tied-first on six of seven complete environments, and was never slower than the RC2 baseline (post-meta approach). On average, the custom-table-with-transients approach was ~52% faster and the purely custom-table approach was ~37% faster than the current implementation. On hosts without a persistent object cache, it landed within 0.05–0.17 ms of plain custom-table—close enough that the two are effectively tied where caching is absent.
Two clean signals showed up in the database query counts during dispatch:
With a persistent object cache present, both transient-based strategies dropped to a single database query per dispatch.
Independent of caching, the custom-table schema cut the query count roughly in half compared to the post-meta strategies.
custom-table-with-transients wins because it gets the schema reduction when caching is absent, and the cache reduction when it’s present. post-meta-transients, by contrast, is not recommended even as a fallback. It nearly doubles in latency without a persistent cache, and on one no-cache shared environment it exhibited a pathological transient code path that pushed dispatch latency past 26 ms — several times worse than any other strategy on that host.
The recommended storage strategy custom-table-with-transients is considered the best case among the candidates. It wins decisively on environments with a persistent object cache, remains comfortably ahead of the baseline on environments without one, and degrades gracefully across the full spread of hosting tiers represented in the data.
The full anonymized analysis—including per-environment dispatch tables, query counts, cross-cuts comparing cache effects, and bootstrap floors—is available here. All submissions remain anonymized in line with the commitment made in the original call for testing.
The data from this testing window was sufficient to make the call confidently: custom-table-with-transients is the best option forward as the default for real time collaboration. When work resumes after clean up from 7.0, this is the approach best positioned to explore more deeply next.
Thank you again to every host that participated. Your contributions provided the data needed to make this storage recommendation and will help set real-time collaboration up for success across the wide range of environments where WordPress runs. Props to Ionos, BlueHost, Kinsta, XServer, and WordPress.com for their contributions here.
Props to @griffbrad for drafting this post. Props to @dd32 @desrosj @jmdodd @peterwilsoncc @jorbin @4thhubbard for testing, analysis, and review. If I missed your name, please tell me as it’s a mistake and there have been a lot of moving pieces.
Fetched May 8, 2026
We've managed to give customers up to 5x performance increase on write-heavy workloads by disabling full-page writes, a Postgres durabiity…