WordPress 7.0 ships soon, and one big feature is missing from the final roadmap. Core decided to remove real-time collaboration from WordPress 7.0. After more than a decade of wrestling with database bottlenecks, I think that was the right call. The latest WordPress Real Time Collaboration performance data shows the first implementation was not ready for the range of hosting environments we deal with every day.
We have all seen what happens when a fun new feature meets a shared host with a bloated wp_options table. It goes badly. So the core team ran tests across eight different hosting environments to find a storage strategy that actually scales. They measured raw dispatch times and query counts during sustained 30-second polling windows.
The four candidates for RTC storage
Four approaches went into the test, all of them handling the high-frequency data that real-time awareness needs, meaning who is editing what right now:
post-meta, the baseline, and the slowest of the four.custom-table, a dedicated table for RTC data.post-meta-transients, which uses transients for awareness but keeps storage in post meta.custom-table-with-transients, the eventual winner, pairing a lean schema with object cache-backed awareness.
I have written before about the friction between real-time editing and object caching, and these results line up with it. The custom-table-with-transients approach came in about 52% faster than the post-meta baseline, and it tied for first in nearly every environment tested.
Why custom tables and transients won
The gain comes from separating high-frequency awareness data, meaning who is in the editor right now, from persistent storage. With a persistent object cache like Redis in place, both transient-based strategies dropped to a single database query per dispatch. That is what lifts WordPress Real Time Collaboration performance: the most frequent requests stop touching the database.
Even without Redis, the custom table cut the query count in half against post-meta. The core wp_postmeta table is a poor fit for frequent updates, since it is a generic key-value store with no indexing suited to RTC-style polling. The core contributors published an anonymized analysis gist with the full benchmarks.
<?php
/**
* A simplified look at how custom-table-with-transients handles awareness.
* This is a conceptual example of why caching the "awareness" layer
* reduces database load.
*/
function bbioon_check_editor_awareness( $post_id ) {
$cache_key = 'rtc_awareness_' . $post_id;
// Attempt to get the awareness data from the transient (Object Cache)
$active_users = get_transient( $cache_key );
if ( false === $active_users ) {
// Fallback to the custom table only if the cache is empty
global $wpdb;
$table_name = $wpdb->prefix . 'rtc_awareness';
$active_users = $wpdb->get_results(
$wpdb->prepare( "SELECT user_id FROM $table_name WHERE post_id = %d", $post_id )
);
// Store in transient for high-frequency polling
set_transient( $cache_key, $active_users, 30 );
}
return $active_users;
}
Where post-meta transients fell apart
The odd result in the data was how badly post-meta-transients did on shared hosts with no persistent cache. On one environment the latency spiked past 26 ms, several times worse than anything else in the test. The WordPress Transients API falls back to the wp_options table when no object cache is present, so if your options table is already struggling, high-frequency RTC polling pours gasoline on the fire.
So the recommendation is custom-table-with-transients. It degrades gracefully on low-end hosts and flies on managed cloud environments with Redis. The WordPress 7.0 release candidate delays were already about performance, and this pivot fits that caution.
If this real-time collaboration work is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
What to take from this
Pulling RTC out of 7.0 was a decision about architecture, not a failure. A custom table strategy gives real-time collaboration room to scale later instead of shipping something that falls over on cheap hosting. If you are building high-traffic features, the same split works: custom tables for your schema, persistent transients for your awareness layer.
