Postgres changes its default compressor, Instagram Live moves to an open ingest protocol, and Cloudflare Radar now opens on an outage map.
Picked from 52 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
Postgres 19 makes LZ4 the default TOAST compressor. It writes faster, but pglz still makes smaller JSON and reads prefixes 16× faster. story 1 ↓
Instagram Live replaced Meta's decade-old RUSH protocol with Media over QUIC for live upload. An edge translator kept the backend unchanged. story 2 ↓
Meta's first goal was matching RUSH, not beating it. That's a practical template for swapping transport protocols under a large system. story 2 ↓
Cloudflare Radar's homepage now opens on a world map of outages and traffic. The post covers design choices only, not engineering. story 3 ↓
1/3PlanetScale· Ahmed Darwich· Oct 12
Postgres 19 switches TOAST compression to LZ4; when pglz still wins
Postgres 19 makes LZ4 the default compressor for oversized values. PlanetScale's tests show LZ4 is usually the better choice, but pglz or no compression is better for some JSON, prefix reads and mid-value reads.
Why it matters · The default compressor decides disk use, write-ahead-log volume, write CPU and read latency for every large text, jsonb or bytea column. Knowing the exceptions lets you tune each column on purpose.
Know this first
Context from the editor, not the article · 31 sec
1 · Postgres pages and rows
Postgres stores table data in fixed 8 KB pages, and a row can't span two pages. Every row has a 24-byte header for transaction visibility. Variable-length types like text, jsonb and bytea also carry a 1- or 4-byte length header.
2 · What TOAST is
TOAST (The Oversized-Attribute Storage Technique) is Postgres's built-in way to handle large column values. It compresses them, or moves them into a hidden side table, so the row fits on its page. It runs automatically, with no application changes.
3 · LZ-style compression
2/3Engineering at Meta· Oct 12
Instagram Live moves video upload from Meta's in-house protocol to open standard
Meta switched Instagram Live's upload path from its own protocol, RUSH, to Media over QUIC, an open standard still in draft. It matched RUSH on quality and reliability, a baseline for later gains.
Why it matters · It shows a working way to swap the transport protocol under a large live system: translate at the edge, route on the server side, and treat parity as the first goal.
Know this first
Context from the editor, not the article · 37 sec
1 · QUIC in one paragraph
QUIC is a transport protocol that runs over UDP and underpins HTTP/3. It carries many independent streams in one encrypted connection, so a lost packet only stalls its own stream. It also sets up connections faster than TCP plus TLS, and a connection can survive a network change.
2 · Ingest versus playback
Live streaming has two legs. Ingest carries video from the broadcaster's device to the platform's servers, historically over RTMP. Playback carries video from servers or a CDN out to viewers, usually over HLS or DASH. Calls often use WebRTC. Each leg tends to have its own protocol and infrastructure.
3 · Head-of-line blocking
3/3Cloudflare· Sophia Alfred· Oct 8
Cloudflare redesigns Radar's homepage around a world map of outages
Cloudflare rebuilt the landing page of Radar, its public Internet-traffic site, to be easier for non-experts. Outages on a world map now lead the page, and tabs replace a grid of competing charts.
Why it matters · If you use Radar to check outages or traffic shifts, the entry point has moved. The post describes the design reasoning and contains no engineering detail.
Know this first
Context from the editor, not the article · 25 sec
1 · What Cloudflare Radar is
Radar is a free public website, launched in 2020, that publishes Internet-wide statistics on traffic, outages, attacks and protocol adoption. The data comes from Cloudflare's network, which the company says handles about 20% of web traffic. Network operators and researchers use it to see regional outages and trends.
2 · Bento box layouts
A "bento box" layout is a dashboard grid of tiles, each holding its own chart or widget, like the compartments of a Japanese lunch box. It shows a lot at once, but every tile gets roughly equal visual weight, so nothing tells the reader what to look at first.
The old Radar homepage: a bento grid of evenly weighted chart tiles.1 / 4
pglz and LZ4 both belong to the LZ77 family. They scan the data and replace a byte run already seen earlier with a short reference: "copy N bytes from X back". How far back they can look is called the window.
Image: PlanetScale
Postgres 19, now in beta, changes the default compressor for oversized values from 1, Postgres's own algorithm, to 2, a fast general-purpose compressor, in builds that include LZ4. PlanetScale already uses LZ4 on Postgres 17 and 18. Ahmed Darwich's post explains what gets compressed and when LZ4 is the wrong choice.
When 3 kicks in
Postgres stores rows in 8 KB pages, and a row can't span pages. TOAST (The Oversized-Attribute Storage Technique) acts only when a whole row exceeds 2,032 bytes, about a quarter of a page. A row with an int and a 2,000-character string is exactly 2,032 bytes, so it is stored uncompressed. Add one character and LZ4 shrinks the value to 26 bytes.
Once a row is over the limit, TOAST works through its variable-length values (text, jsonb, bytea), largest first. It compresses each one, or moves it to a side table in roughly 2 KB chunks, until the row fits. Random data that won't compress is moved out raw. A 1.1 MB repeated sentence compressed to 4,471 bytes, which was still too big, so it was moved out as well. A column's storage strategy controls what TOAST may do. For example, EXTERNAL means "move out, never compress".
pglz vs LZ4
Both replace repeated bytes with back-references. pglz looks back 4 KB, searches for the longest match, and keeps a result only if it saves more than 25%. LZ4 looks back 64 KB but checks a single candidate, which is much faster. In a test with words repeating about 35 KB apart, pglz couldn't compress the value at all, while LZ4 saved about 15%.
pglz still wins in two places:
Repetitive JSON: on 10,000 order documents, pglz produced 19 MB, LZ4 24 MB, and uncompressed 103 MB. LZ4 loaded faster: 0.48–1.09 s against 1.59–1.73 s.
Prefix reads: pglz's format puts a ceiling on how many compressed bytes a prefix can need. Reading 200 characters therefore touches only the first chunk: 301 page lookups in about 1 ms, against 6,234 lookups in about 16 ms for LZ4.
When to skip compression
Use EXTERNAL for data that is already compressed, like JPEGs, and for large bytea values read from the middle. Uncompressed chunks hold a fixed number of bytes, so Postgres can jump straight to the right one. Reading 200 bytes at offset 500,000 took 0.6 ms uncompressed, 43 ms with LZ4 and 116 ms with pglz.
Changes to a column's compression apply only to new writes. Existing values keep their algorithm even through VACUUM FULL. Darwich concludes that LZ4 is the right default for most tables, with pglz or EXTERNAL chosen deliberately for the cases above.
Postgres 19, now in beta, changes the default compression for oversized column values from 1, Postgres's own compressor, to 2, a widely used fast compressor. This applies to builds compiled with LZ4 support. PlanetScale has already made the switch on its Postgres 17 and 18 offerings. In a post on its blog, Ahmed Darwich explains which values get compressed, what happens to them, and the cases where LZ4 is the wrong choice.
Where a row's bytes go
Postgres stores rows in 8 KB pages, and a row can't be split across pages. Each row starts with a 24-byte header. Fixed-width columns follow it: bigint (8 bytes), timestamptz (8) and boolean (1). Variable-length columns (text, jsonb, bytea) take the size of their data plus a length header. That header is 1 byte for values up to 126 bytes and 4 bytes for anything longer. So ROW(1::bigint, now(), true, 'Ada') costs 45 bytes: 24 for the header, 17 for the fixed columns, and 4 for "Ada". Only variable-length values make a row grow, and only they can be compressed.
The 2,032-byte threshold
3 (The Oversized-Attribute Storage Technique) steps in only when a whole row exceeds 2,032 bytes, set by the table's toast_tuple_target. That is about a quarter of a page, chosen so at least four rows fit on each page.
The post shows the edge exactly. Take a table with an int key and a text column:
A 2,000-character string of x makes the row 24 + 4 + 2,004 = 2,032 bytes. That is right at the limit, so the value is stored uncompressed.
One more character puts the row over the limit, and LZ4 shrinks the value to 26 bytes.
Many medium-sized values never get compressed at all.
Two jobs: compress, or move out
The threshold applies to the row, but TOAST works on individual values, from largest to smallest. It stops as soon as the row is back under 2,032 bytes. For each value it can either compress the value and keep it in the row, or move it out. Moved values go to a TOAST table, created automatically in the pg_toast schema. There the value is split into chunks of up to 1,996 bytes, each stored as its own row tagged with chunk_id and chunk_seq. Four chunk rows fit on a page. The original row keeps an 18-byte pointer to the chunks.
A four-row demo shows every outcome:
Value
Raw
Stored
Result
200 × x
200 B
204 B
untouched
abc × 3,400
10,200 B
60 B
compressed, stays in the row
random hex
200,000 B
200,000 B
doesn't compress, moved out raw
repeated sentence
1,125,000 B
4,471 B
compressed, still too big, moved out
Each column's storage strategy limits what TOAST can do with it:
PLAIN: nothing. Used by fixed-width types.
EXTENDED: compress, then move out if needed. The default for text, jsonb and bytea.
EXTERNAL: move out, never compress.
MAIN: compress, and keep the value in the row while it still fits on the page.
Changing a column's strategy, or its COMPRESSION setting, affects only values written afterwards. Already-compressed values keep their algorithm even through INSERT ... SELECT or VACUUM FULL. zstd isn't available for column compression. Postgres uses it only for 4 compression and backups.
TOAST is different from Postgres 5, which you create explicitly (lo_import) and which live in pg_largeobject. TOAST values are capped at 1 GB and are deleted with their row. Large objects go up to 4 TB and stay until you call lo_unlink. Anything over 1 GB has to be a large object.
How the two algorithms differ
Both algorithms replace repeated bytes with back-references. They differ in how far back they can look and how hard they search:
pglz has a 4 KB window. At each position it checks several earlier matches and keeps the longest. Postgres throws away the result unless it saves more than 25%.
LZ4 (supported since Postgres 14) has a 64 KB window, but checks only one candidate from a small hash table. Newer entries keep overwriting older ones, so distant repeats are found less reliably. That single check is what makes it fast. Postgres keeps any LZ4 result that saves more than 2 bytes.
To test the window, Darwich built a roughly 210 KB string from 30,000 random six-character words. He built it twice: once from a 500-word vocabulary, where a word repeats about 3.5 KB later on average, and once from 5,000 words, about 35 KB later.
500 words: pglz produced 105,457 bytes and LZ4 96,022, about 9% smaller. Roughly 30% of repeats fell outside pglz's 4 KB window.
5,000 words: pglz couldn't reach the 25% savings bar, so the value was stored uncompressed (209,999 bytes). LZ4 still got it down to 177,590, about 15% smaller.
Where pglz wins
Repetitive JSON. The test used 10,000 order documents with 25–100 line items each, every item repeating the same five keys. The keys sit close together, so both algorithms find them, and pglz's extra searching finds longer matches. Table sizes were 103 MB uncompressed, 19 MB with pglz and 24 MB with LZ4. LZ4 loaded faster: 0.48 s and 1.09 s across two runs, against 1.59 s and 1.73 s for pglz.
Prefix reads. For a query like left(body, 200), pglz's format guarantees at most 9 bits per original byte plus 2 bytes. Postgres can therefore calculate a ceiling. 200 characters are at most 800 bytes in UTF-8, which need at most 902 compressed bytes. That fits in the first 1,996-byte chunk, so only one chunk is fetched. LZ4 has no such bound, so Postgres fetches the whole value first. The test used 100 values of about 1 MB, which each algorithm compressed to about half their size. pglz needed 301 page lookups (about 1 ms) and LZ4 needed 6,234 (about 16 ms). Uncompressed EXTERNAL also needed 301 lookups but used about twice the disk.
When not to compress
Compression saves disk, keeps more of the table in memory, and cuts WAL volume sent to replicas and backups. It costs CPU on every write over the threshold and every read of a compressed value. It doesn't reduce network egress, because values are decompressed before they are sent to the client. The post recommends EXTERNAL in two cases:
Data that is already compressed, such as JPEG frames. LZ4 spends CPU and saves almost nothing.
Large bytea values read from the middle. Uncompressed chunks hold exactly 1,996 bytes each, so byte 500,000 must be in chunk 250, and Postgres fetches only that chunk. With compression there is no telling where a byte lands, so Postgres decompresses from the start. Reading 200 bytes at offset 500,000 took 0.6 ms with EXTERNAL, 43 ms with LZ4 and 116 ms with pglz. This shortcut works only for bytea. UTF-8 text has variable-width characters, so Postgres always reads it from the start.
The verdict
Darwich concludes that LZ4 is the right default for most tables, because its speed matters more than a size difference that can go either way. Choose pglz or EXTERNAL by hand for the cases above. The published text cuts off just before its final list of recommendations. Note too that the JSON timings come from only two runs each, on PlanetScale's infrastructure.
Remember
Values below the 2,032-byte row threshold are never compressed, however compressible they are.
Changing a column's compression or storage setting doesn't rewrite existing values, even through VACUUM FULL.
Reading from the middle of a large bytea is about 70× faster uncompressed (EXTERNAL) than with LZ4.
TCP delivers one ordered byte stream. If a packet is lost, every byte behind it waits for the retransmission, even bytes from unrelated media. For live video this turns brief loss into growing delay, which is a main reason platforms have moved media onto QUIC.
Meta's comparison of media protocols by latency and scale, showing where it positions MoQ against the others.
Instagram Live now sends broadcasters' video to Meta's servers (the "ingest" leg) over 1 on iOS and Android. MoQ is an open media protocol that the 2, the internet's standards body, is still drafting. The goal for this phase was parity with the protocol it replaced, not improvement. Meta reports that MoQ matched it on every quality and reliability metric used in the rollout, but publishes no numbers.
Why switch
For nearly a decade, Meta's live video ran on 3, its in-house QUIC-based replacement for the older 4 ingest protocol. RUSH worked, but Meta evolved it alone. Across the industry, ingest, playback (HLS/DASH) and calls (5) each have their own protocol, so a single user session can touch three stacks with separate infrastructure and on-call knowledge. Meta argues that one standard transport, shaped by Google, Cloudflare, Cisco and others, would cut that sprawl.
How MoQ works
Media flows as 6: addressable streams of objects that publishers push and subscribers pull through relays. Relays cache and fan out using only MoQ metadata and never parse the video. Because MoQ runs on QUIC, a lost packet stalls only its own stream. Each subscriber can choose its latency: about 100 ms for a co-host and several seconds for an archiver, on the same track. Relays can drop stale objects under congestion instead of queuing them.
How they swapped it
Client: the apps use 7, Meta's open-source MoQ library, on its QUIC stack 8. One config flag picks MoQ or RUSH for each broadcast.
Edge translation: MoQ connections end at edge servers that convert frames to RUSH format, so the backend didn't change. Meta describes this as temporary.
Server-side routing: stream URLs point experiment-group broadcasts to MoQ endpoints. The ramp didn't depend on users updating their apps and could be resized in minutes.
Three things got in the way. The draft spec kept changing, so Meta pinned draft versions and kept shims for older clients. Some enterprise and carrier networks block UDP port 443, so the client races TCP against QUIC at stream start and keeps the winner, using RUSH's TCP fallback for now. And QUIC's encryption hides framing from packet captures, so the team built MoQ-aware tracing into the edge.
What's left
Latency and resilience gains are still to come. Meta's next targets are end-to-end MoQ playback with partial reliability (skipping stale video instead of building up delay), separate streams for audio, video and metadata, and 9, a standard TCP fallback. QMUX would finally let Meta retire RUSH. Until then RUSH remains both the backend format and the fallback path, and the post doesn't say how often that fallback is used.
What shipped
Instagram Live now uses 1 to carry video from broadcasters' phones into Meta's servers on iOS and Android. MoQ is an open media protocol that the 2 (Internet Engineering Task Force) is standardizing. This leg of a stream is called ingest. Sending video out to viewers is called playback. For this phase Meta did not aim for a faster or smoother stream. The target was parity: after months of experiments, MoQ had to match the protocol it replaced on every streaming-quality and reliability metric used in the rollout. Meta reports that it did. The post gives no numbers for those metrics, and none for stream counts or volume. It calls the deployment "one of the largest application usages of MoQ we are aware of".
Why replace a protocol that worked
Meta's case is about how many protocols it has to run. The industry uses 3 (Real-Time Messaging Protocol) for ingest, 4 (HTTP-based segmented streaming) for playback, and 5 for real-time calls. Meta added its own: 6 (Reliable Ultra-low-latency Streaming over HTTP), a QUIC-based replacement for RTMP that has carried Meta's live video for nearly a decade. A user who starts a live stream and then makes a voice call in the same app touches three protocol stacks. Each has its own serving infrastructure, monitoring and operational expertise. Meta argues that live video, calls and interactive features now share the same product surfaces, so one transport across ingest, delivery and playback would cut the number of custom stacks its teams maintain.
RUSH was stable and performed well, and Meta says it proved QUIC could carry live media at scale. But Meta evolved it mostly alone. MoQ moves that work into a standards effort where Google, Akamai, Cisco, Cloudflare and academic groups also implement, test interoperability and refine the spec.
Meta gives three reasons for choosing Instagram Live ingest as the first workload:
it is Meta's largest live surface, so it is the hardest test;
RUSH was falling behind the open ecosystem;
proving parity there gives a clean baseline for everything that follows.
How MoQ works
MoQ's core abstraction is the 7: an addressable stream of media objects. Publishers push objects into a track, and subscribers receive them through a network of relays. Relays cache and forward objects using only MoQ's framing and delivery metadata. They never parse the video itself. Meta highlights these properties:
An illustrative example (not from Meta's numbers): a creator publishes a video track. A co-host subscribes at about 100 ms latency, and an archiving service subscribes several seconds behind. If the co-host's link congests, a relay can drop stale objects for that subscriber so delay doesn't build up, while still sending everything to the archive. On a single TCP byte stream, one lost packet holds up every byte behind it for every consumer of that connection.
The migration
Meta says the hard parts had little to do with the protocol itself. Broadcaster apps had to learn it. The backend expected RUSH framing. The rollout had to be reversible in seconds. And some networks can't carry QUIC at all. The team handled three constrained problems:
Client integration across four apps. The apps include a MoQ publisher built on 9, Meta's open-source MoQ library. moxygen provides publisher, subscriber and relay roles and runs on 10, Meta's QUIC implementation. A single config parameter picks MoQ or RUSH for each broadcast.
Translation at the edge. MoQ connections terminate on dedicated edge endpoints, where a translator converts MoQ frames into the RUSH format. Nothing downstream changed. Meta calls this "temporary scaffolding" that goes away once the backend consumes MoQ natively.
Operational hurdles
A moving spec. The MoQ draft kept changing during the build. Meta pinned specific draft versions, kept compatibility shims for older clients, and sent fixes back to the working group.
Firewalls. UDP port 443 is still blocked or rate-limited on a "non-trivial slice" of enterprise and carrier networks. The client races a TCP handshake against a QUIC handshake at stream start and uses the winner for the whole session. For now the TCP path relies on RUSH's existing fallback.
Debugging. QUIC's encryption hides framing from middleboxes and from Meta's own packet captures. The team built MoQ-aware tracing into the edge so it could see object-level events without decrypting traffic.
What it adds up to, and what's open
The result so far is a transport swap with nothing visible to users, plus rollout controls and observability for the next phase. Latency and resilience gains are still to come. Meta's target architecture pushes media as it is produced and uses partial reliability: after loss, the player skips stale video instead of falling further behind, and adaptive bitrate trades resolution for continuity. Next steps on ingest are to:
extend MoQ to Meta's other apps;
use MoQ subgroups to carry audio, video and metadata on independent streams;
adopt QMUX for TCP fallback, which would let Meta retire RUSH.
Meta also names real-time, two-way interactive features as a possible future workload.
The post leaves several things unanswered. It publishes no metric values, so "parity" can't be checked from outside. It doesn't say what share of sessions fall back to TCP, or what the edge translator costs. It doesn't mention the CPU cost of running QUIC in user space at this scale. And RUSH is still in the path twice, as the backend format and as the TCP fallback, so the simplification the project promises hasn't happened yet.
Remember
Treating parity as the goal let Meta separate the protocol swap from feature work.
An edge translator into the old wire format meant no backend system changed during the migration.
RUSH survives as the backend format and TCP fallback until native MoQ and QMUX arrive.
Cloudflare has redesigned the landing page of 1, its free public site for Internet-wide data on traffic, outages and attacks. The data comes from Cloudflare's network, which the company says handles about 20% of web traffic. Since its 2020 launch, Radar has mostly served network operators and academic researchers. Designer Sophia Alfred writes that the goal now is to reach journalists, human rights advocates, policymakers and the general public without making the data shallower.
This is a design write-up. It contains no engineering detail and no usage or testing numbers.
What was wrong
The old homepage was a "2" grid of chart tiles. Every tile had similar visual weight, the vertical cards broke normal reading order, and the styling didn't match the rest of Cloudflare's sites. One user told the team Radar was hard to show to his students, which they read as a sign that it intimidated newcomers. Alfred argues that looking consistent with Cloudflare also builds trust, because a familiar style signals an authoritative source.
The new layout
A world map at the top. It shows outages first, as the most concrete and timely signal, and traffic second, to show how much Radar covers. The map also works as navigation into countries, trends and data stories.
Tabs instead of tiles. Below the map, each tab gives a few summary statistics and a link to the full data. Readers see one topic at a time instead of everything at once.
Design choices
The team placed Radar where three kinds of Cloudflare sites overlap: marketing pages, content sites (blog and docs) and product interfaces. The new design is approachable like marketing, structured like docs, and built on 3, Cloudflare's shared library of product UI components, to make it easier to maintain.
The map took several rounds. Early versions were dense with data, which looked credible but overwhelmed people. Later versions looked like marketing material, which was friendlier but made live data feel static. The final version sits between the two.
What's missing
The post includes no usability results or analytics to show the redesign works. It doesn't address how a country map can make big countries look important and hide outages in small ones. It also says nothing about the data pipeline or what the move to Kumo involved. Cloudflare is asking for feedback at [email protected].
What changed
Cloudflare has redesigned the landing page of 1, its public website for Internet-wide data such as traffic volumes, outages and security trends. Radar launched in 2020. According to designer Sophia Alfred's post, its core audience has been technical: network operators and academic researchers who follow industry trends and global events. The redesign aims at a second audience of journalists, human rights advocates, policymakers and curious members of the public, without giving up the depth the experts rely on.
This is a product-design story, not an engineering one. The post says nothing about how Radar's data is collected, stored, aggregated or served, and gives no usage numbers or before-and-after metrics.
What was wrong with the old page
Alfred names three problems with the previous homepage:
Flat hierarchy. The page used a "2" layout, a grid of chart tiles. Every tile got similar visual weight, so a newcomer had no clear starting point.
Awkward reading order. Vertical cards broke the usual left-to-right, top-to-bottom way people scan a page.
Brand disconnect. The styling didn't look like the rest of Cloudflare's sites.
One piece of user feedback carried weight: an external user, apparently a teacher, said Radar was hard to show to his students. The team read that as a sign that Radar intimidated first-time visitors. Alfred argues the brand point matters more than it might seem. If Radar looks like the rest of Cloudflare, outsiders are more likely to see it as authoritative. Familiar layout patterns also make dense information easier to move through.
The new layout
The page now opens with a world map. Alfred concedes the Internet largely ignores national borders, but argues that geography is how most people connect it to everyday life. The top section covers two things:
Outages, which come first because they are the most concrete and timely signal about the state of the Internet.
Traffic, which shows how much data Radar covers.
The map is also the main way in. From it, readers move to individual countries, trends and longer data stories.
Below the map, the old chart tiles became a tabbed flow. Each tab shows a few summary statistics and a link to the full data. In effect the page runs as a funnel: map first, then the summaries, then the detailed views. Only one topic is on screen at a time, so the page previews Radar's range without showing everything at once.
Where Radar sits in Cloudflare's design system
The team sorted Cloudflare's web presence into three groups: marketing pages (cloudflare.com), content sites (the Cloudflare Blog and Developer Docs) and product interfaces. They decided Radar belongs to all three. It is a data product, but it is also public and full of content. So the design borrows from each:
approachable, like marketing pages;
structured and easy to navigate, like the blog and docs;
built on 3, the shared UI component library behind Cloudflare's product interfaces, to make it easier to maintain.
The move to Kumo is the one detail that matters for engineering. Building on a shared component library cuts down on one-off front-end code that has to be maintained separately. The post doesn't say how big the migration was or how it went.
How the map evolved
The map went through several rounds of design. Early versions were packed with data, an attempt to look credible through sheer density. Later versions swung toward polished marketing visuals. Those were friendlier, but they made live data look static or over-summarized. The final design sits between the two: it still feels like live data, but it's easier to read. Alfred frames this as the central trade-off of the project, between richness of data and approachability.
What the post leaves open
The post is short, and several obvious questions go unanswered:
No evidence of impact. There are no usability-test results, analytics, or comparisons of how new visitors behave before and after.
No look at the map's own biases. Country maps tend to make large countries look important and hide outages in small ones or in specific networks. The post doesn't say how the design handles this.
Nothing on implementation. The post doesn't cover how fresh the map's data is, what powers the outage layer, or what the Kumo migration cost.
The post ends by inviting feedback through @CloudflareRadar on X, radar.cloudflare.com on Bluesky, or [email protected]. It promises more tools and visualizations for new audiences while Cloudflare keeps investing in the underlying data infrastructure.
Remember
Outages now lead Radar's homepage, chosen as the most concrete and timely signal of Internet health.
The design moved Radar onto Kumo, Cloudflare's shared product component library, to make it easier to maintain.
The post offers no usability metrics, so whether newcomers find Radar easier is still unshown.
Built on QUIC. Independent streams do not block one another, connections set up faster and can migrate between networks, and any future QUIC feature (Meta mentions forward error correction) comes along automatically. Meta's earlier QUIC rollout cut request errors, tail latency and video stalls compared with HTTP/2.
Fan-out and caching in the protocol. Relays coalesce duplicate requests, cache, and fan out to many subscribers by design, not as a CDN add-on.
Latency set per subscriber. Two subscribers to the same track can run at different latencies at the same time.
Track-aware delivery. Relays can drop, prioritize or replay objects based on metadata.
Media built into the protocol. Tracks and their quality variants are protocol constructs, so adaptive bitrate logic (switching quality as bandwidth changes) builds on them directly.
Standard TCP fallback through WebTransport over HTTP/2 or the emerging 8 mapping.
Server-side routing. When the server generates a stream URL, it sends broadcasts in the experiment group to MoQ-capable endpoints. The ramp therefore didn't wait on users updating their apps, and the experiment could be resized in minutes.
