When WordPress core contributors pulled real-time collaboration from the 7.0 release, they left an open question: which storage architecture should the feature be built on going forward? Data collected across eight hosting environments between April 29 and May 4 has now produced a clear answer, and work on the feature will resume around that choice once the 7.0 cleanup wraps up.
Four storage strategies were put through sustained 30-second polling tests, with contributors measuring per-request REST dispatch time — the time WordPress takes to process each REST API request — and database query counts. The field included post-meta (the baseline carried over from Release Candidate 2, or RC2), custom-table, post-meta-transients, and custom-table-with-transients. Environments ranged from shared hosting with no persistent object cache — a server-side memory layer such as Redis or Memcached that stores data between requests — to managed cloud setups running Redis. On average, custom-table-with-transients was roughly 52% faster than the current post-meta baseline, while the plain custom-table approach was about 37% faster.
The query count data reinforced the dispatch time results, with two consistent patterns emerging: hosts with a persistent object cache saw both transient-based strategies drop to a single database query per dispatch, and the custom-table schema cut query counts roughly in half compared to post-meta strategies regardless of caching. The table below summarizes how each strategy performed:
| Storage strategy | Avg. dispatch time vs. baseline | Queries with object cache | Without object cache |
|---|---|---|---|
| post-meta (RC2 baseline) | baseline | multiple queries per dispatch | multiple queries per dispatch |
| custom-table | ~37% faster | roughly half the queries of post-meta | roughly half the queries of post-meta; within 0.05–0.17 ms of custom-table-with-transients |
| post-meta-transients | worse than baseline; one shared host exceeded 26 ms dispatch time | 1 query per dispatch | latency nearly doubled; not recommended even as a fallback |
| custom-table-with-transients (recommended) | ~52% faster | 1 query per dispatch | matches custom-table performance |
Custom-table-with-transients won because it captures both benefits depending on the environment: schema savings when caching is absent, and cache savings when it is present. The post-meta-transients approach performed poorly enough to be ruled out even as a fallback — without a persistent object cache it nearly doubled in latency, and on one shared environment with no cache it hit a problematic code path far worse than any other strategy on that same host.
On hosts without a persistent object cache, custom-table-with-transients landed within 0.05–0.17 ms of plain custom-table, meaning the two are effectively tied in uncached environments. The advantage of the recommended strategy is that it scales up automatically when object caching is available, without requiring any configuration change.
The full anonymized analysis, including per-environment dispatch tables, query counts, and cache effect comparisons, has been published on Make WordPress Core. Submissions were kept anonymous in line with the original call for testing. Participating hosts included Ionos, Bluehost, Kinsta, XServer, and WordPress.com.
