Summary
- The published table ranks exchange entries by recorded peering capacity for ten global networks. It places three Brazilian IX.br locations in the top six, but lists the distributed NL-IX footprint as one entry.
- That is a site-level comparison, not a ranking of exchange operators, national systems or traffic. NIC.br’s figures for IX.br describe a different, much broader measurement.
A row is not an operator
A ranking can be useful and still answer a narrower question than its headline suggests. In Gael Hernandez’s analysis, three entries associated with IX.br—São Paulo, Rio de Janeiro and Fortaleza—appear separately near the top. The same analysis describes NL-IX as a single entry even though its footprint covers more than eight countries, 83 facilities and 12 cities. Those records can all be informative. They do not all represent the same geographic unit.
The distinction matters because readers often move quickly from a table of sites to a conclusion about institutions or regions. “Three Brazilian entries among the top six” is a statement about the entries the study ranks. It is not evidence that Brazil has three independent exchange systems of comparable scope, nor that those sites carry a particular share of South American traffic.
The analysis says it aggregates PeeringDB capacity for ten named network brands: Akamai, Meta, Amazon, Hurricane Electric, Cloudflare, Fastly, Microsoft, Google, Netflix and ByteDance. Its first three entries are IX.br São Paulo, DE-CIX Frankfurt and Equinix Singapore. It reports 22.8 Tbps for São Paulo, and identifies three Brazilian entries in the top six. The headline result is therefore built around exchange-level records: where capacity is recorded for those networks at the listed exchange entries.
That is a legitimate lens. A network planner asking where large content or cloud networks report peering capacity may care about individual locations. A location-level list can point to places worth investigating and can help distinguish one metropolitan interconnection market from another. The problem begins only when a reader treats each row as if it described the same kind of operator-wide footprint.
The table hides two different boundaries
IX.br is a distributed system. NIC.br says it is present in 39 metropolitan areas across Brazil’s five regions, with about 3,800 participating autonomous systems and roughly 7,000 connections. Its March 2026 release reports a record 50 Tbit/s of aggregate traffic on 20 March, including 32 Tbit/s at São Paulo. These are operator-level figures about IX.br’s broader footprint and a dated traffic observation.
They should not be used to validate the PeeringDB ranking’s capacity arithmetic. The ranking and the NIC.br release describe different measurements, populations and boundaries. One reports capacity recorded for selected networks at exchange entries; the other reports traffic through IX.br. Dividing one by the other would not produce a utilization rate. Nor does a national or system-wide traffic figure tell us how the selected networks’ traffic was distributed among the ranked locations.
NL-IX makes the grouping question visible from the other direction. The study counts one NL-IX entry while describing a footprint across more than eight countries, 83 facilities and 12 cities, with over 525 participants. A single row can therefore stand for a geographic system much wider than a city. Three rows can stand for three local IX.br sites within one national system. The table is not necessarily wrong; it is mixing a local-site view with an operator whose listed entry already spans many sites.
The public analysis does not give readers a record-by-record mapping that would settle every grouping choice. It identifies PeeringDB as its source and warns that exchange presence and port-capacity values may be incorrect or out of date. PeeringDB’s network-to-exchange connection model exposes fields such as network, exchange, speed, status and update time. Those fields help describe what a record contains; the schema alone does not reveal which records Hernandez included, when they were extracted, how missing values were handled, or whether similarly named locations were grouped.
Capacity is not use
“Capacity” also needs to stay in its lane. A declared port speed or an aggregate of listed peering capacities is not an observation of traffic, successful forwarding, utilization, path locality or resilience. The analysis itself cautions that its source records may be stale or inaccurate. A high listed value may make an exchange entry worth examining, but it cannot show how much traffic actually traversed it during a particular interval.
The distinction is not an argument against using PeeringDB. It is a reason to label the object clearly. A database record can support a transparent comparison when the analyst publishes the extraction date, record identifiers, inclusion rules and aggregation method. Without those details, readers can repeat the ranking as a reported result, but cannot independently reconstruct every row or tell whether a changed position reflects new interconnection, corrected records or a changed grouping rule.
IX.br’s participation information makes the site boundary operational rather than merely cartographic. An autonomous system can seek to exchange traffic at a locality, select a physical interconnection point or shared-port provider, arrange the connection and complete the relevant enrollment and technical steps. Costs differ by locality. A network considering São Paulo and Fortaleza is evaluating two local connection decisions, even if both sit within IX.br. That is why site-level rankings can be useful without being operator-level rankings.
Analysis: publish both views
The cleanest presentation would keep the site-level table and add a second, explicitly grouped view. The first would rank exchange locations. The second would compare operator footprints under a published rule: which records belong to one system, how multi-country or multi-city networks are handled, and what happens when a brand operates several separately named exchanges.
Each edition should carry a dated snapshot, stable exchange and network identifiers, the selected records, a short explanation of exclusions, and a reproducible aggregation rule. A separate mapping table could show the path from individual site records to an operator group. That would let a reader move between the local market and the wider system without silently treating them as equivalent.
Until then, the strongest conclusion is narrow but useful: three Brazilian locations place high in this particular recorded-capacity ranking for the selected networks. The table does not establish that Brazil has three separate operator systems at the same scale as its peers, that the three sites carry the most traffic, or that the ranking measures regional dependence. Those are different questions, and each needs a different denominator.
Sources
- Gael Hernandez, “Peering Capacity at Public Internet Exchanges: What the Data Reveals,” LACNIC republication
- Original analysis on RIPE Labs
- NIC.br release on IX.br’s March 2026 traffic record and footprint
- IX.br São Paulo participation information
- PeeringDB API documentation for network-to-exchange records
- PeeringDB API specifications
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
