There’s a familiar tension in enterprise technology: buy a fully integrated platform or assemble a stack of best-of-breed components. The platform story is compelling: one vendor. One console. One contract. Everything bundled together.
The best-of-breed story is different. Best-of-breed optimizes each layer for performance, flexibility, and cost. Historically, platforms often won the narrative. But in periods of rapid change—like today’s AI era—modularity regains the advantage.
The platform gravity problem
Platforms can introduce operational gravity. When compute, storage, networking, analytics, governance, and AI tooling all live in one ecosystem, switching costs rise over time. What starts as convenience becomes constraint—and in AI, where tooling changes rapidly, that becomes expensive in both flexibility and economics. Industry leaders reflect this shift. CIOs are moving beyond a “cloud-first” mindset toward “cloud-smart” strategies and choosing the right environment for each workload instead of defaulting to one provider’s stack. This proactively avoids escalating costs and inflexible ecosystems. A recent CIO Dive trend report finds many IT leaders are gravitating toward purpose-built infrastructure optimized for specific workload demands—including AI—rather than broad commodity offerings.
Why modular infrastructure wins
AI pipelines evolve constantly: training datasets, checkpoints, GPU migrations, MLOps workflows and post-processing outputs are all subject to rapid changes to scale applications and extend model capabilities. Few organizations run all of that inside a single vendor environment or a single cloud ecosystem. Teams building differentiated systems optimize workflows and resources, not monoliths.
Modularity isn’t just about avoiding lock-in—it’s about real, measurable agility. Modular architectures allow organizations to adjust components independently as requirements change. CTOs are intentionally placing workloads where they perform best—cloud for global scale, on-prem or colocation for heavy AI training, and edge for low-latency inference—and treating each as part of a unified, purpose-driven infrastructure strategy.
This pattern holds true beyond just AI.
In cyber resilience, what matters when a ransomware event hits isn’t whether you bought every tool from one vendor; it’s the speed and predictability of recovery (which specialized, resilient storage does more to accelerate than bundled dashboards)
In cloud native application development, developers value predictable performance, clear pricing, and flexibility over being locked into a single ecosystem.
In media and entertainment, workflows often span regions, partners, and technologies—moving petabytes of creative content, generating AI media assets, and orchestrating distributed rendering jobs. A modular approach enables teams from all sides of the business (creative and technical) to optimize for performance without constraint.
These use cases share common themes: avoid lock-in, preserve optionality, control costs, and maintain performance predictability. These align with broader industry sentiment that hybrid and composable architectures deliver greater agility and resilience in the face of evolving requirements.
Depth over breadth: A focused infrastructure philosophy
When vendors expand aggressively into adjacent domains—analytics, governance, AI tooling—they risk breadth at the expense of depth. In fast-moving markets, “jack-of-all-trades” platforms often become “master-of-none.” Best-of-breed doesn’t mean disjointed; it means each layer is optimized for its purpose and integrated intelligently.
That’s the philosophy behind how we’ve evolved our own infrastructure. When Backblaze first launched our object storage service, we highlighted performance, transparency, and cost efficiency. As AI and high-throughput workloads accelerated, customers began using us as neutral infrastructure for staging, throughput, and data mobility between clouds. We leaned deeper into storage—high-throughput tiers, bandwidth guarantees, lifecycle tools—but intentionally stopped short of climbing higher up the application or analytics stack.
We draw a line at storage not because adjacent layers lack value, but because storage is foundational. AI differentiation, application logic, and workflow intelligence happen above the infrastructure layer. Customers need owned, interoperable workflows that can plug into any compute or AI platform without being co-opted by a monolithic ecosystem.
Modular infrastructure as a strategic backbone
Best-of-breed doesn’t mean fragmentation; it means focus with composability. The future of enterprise infrastructure isn’t about building the tallest platform—it’s about building the strongest foundation that supports innovation across many dimensions.
Across industries, infrastructure leaders are embracing workload placement strategies and hybrid models to optimize for cost, governance, and performance. In AI, this means hybrid cloud and on-prem strategies where appropriate; in traditional application and file storage, it means interoperable, resilient services; and in media workflows, it means performant pipelines unencumbered by monolithic stack limitations.
The companies that win in this era won’t be those who own every layer. They’ll be those who enable others to build faster, iterate often, and adapt without constraint.
AI cloud platforms have spent the last few years competing on GPU availability, interconnects, and cluster performance. That makes sense. GPUs are the engine of AI infrastructure, and demand for them has been relentless.
But a GPU can only work as fast as the data pipeline feeding it.
Think of it like a fleet of race cars. You can have the best cars on the track, the fastest pit crew, and a perfect race strategy. But if the fuel lines supplying the pit tanks can’t move gasoline fast enough, the cars are going to sit there waiting.
The cars are not the problem. The fuel supply system is.
The same thing happens in AI infrastructure. GPUs rely on high-performance flash storage when training models or running inference. But before data can be served from that flash tier, it often needs to move from durable object storage into the performance layer. If that upstream object storage layer can’t deliver data quickly and consistently, the entire pipeline slows down.
That’s why GPU availability is only half the equation. The other half is the data supply architecture that keeps those GPUs working.
The hidden bottleneck in AI infrastructure
AI workloads move a lot of data, constantly. Training datasets need to be staged and prepared so jobs can access them quickly. Model checkpoints, artifacts, embeddings, and intermediate outputs need to be written back for durability and reuse. Inference pipelines generate their own steady stream of reads and writes as models serve predictions and capture outputs.
All of that activity puts pressure on the storage and networking layers underneath the AI platform.
The bottleneck usually does not come from one obvious failure. Instead, it builds from a few things happening at once:
Data retrieval slows down under load.
Network paths become congested.
Request overhead compounds at dataset scale.
I/O behavior becomes less predictable as concurrency increases.
Individually, each of these may seem manageable. Together, they can quietly limit how efficiently AI infrastructure runs.
And the problem gets more visible as platforms scale. A handful of GPUs might be fine, while dozens or hundreds of GPUs create a very different demand profile. The upstream storage layer has to sustain much higher aggregate throughput while also absorbing frequent checkpoint and artifact writes.
Adding more GPUs increases potential compute capacity. But it also increases the rate at which data has to move.
Without enough throughput from the upstream data layer, more compute does not automatically translate into more performance.
Idle GPUs are expensive GPUs
When GPUs wait on data, the impact is both technical and financial.
First, idle GPUs waste compute capacity. GPU time is expensive, and AI workloads are designed to keep those processors busy. When the data pipeline can’t keep up, organizations end up paying for compute that is not being fully used.
Second, data delays slow development. Training runs take longer. Clusters stay reserved for more time. Teams wait longer to evaluate results. Even small drops in utilization can raise the cost of AI work because each run takes longer to finish.
Over time, that means slower iteration, delayed experiments, and longer paths to new models and features.
For AI cloud platforms, the risk is even bigger. Customers judge the platform by outcomes: how quickly jobs start, how consistently workloads run, and whether performance scales as expected. If jobs take longer than expected or results vary from run to run, customers may assume the GPUs are the issue.
But the real problem may be that the data pipeline can’t deliver data fast enough.
AI changes what object storage needs to do
Object storage has traditionally been evaluated around durability, scalability, cost, and general-purpose cloud performance. Those still matter, and AI infrastructure adds a new requirement: sustained data movement.
AI workloads require an object storage layer that can continuously supply downstream performance tiers under real-world load.
That means object storage needs to:
Sustain high aggregate throughput, not just short bursts.
Deliver predictable performance under continuous data movement.
Absorb large checkpoint and artifact writes.
Quickly rehydrate data when needed.
Many traditional object storage architectures were not built for this kind of steady, high-volume supply model. They can perform well for archival workloads, backups, and general-purpose applications, but AI introduces sustained pressure that exposes architectural limits.
The result is rarely a dramatic failure. More often, it looks like variability. Performance fluctuates under load. Scaling becomes harder to predict. GPU clusters wait on data more often than they should.
That variability becomes a competitive problem.
For AI clouds, storage is now part of the product experience
GPU availability is becoming table stakes. What separates platforms is not just how many GPUs they advertise, but how reliably those GPUs translate into real-world AI performance and productivity.
We said that customers care about outcomes. They want models to train faster. They want workloads to stay stable as they scale. They want infrastructure that helps them iterate quickly instead of introducing another bottleneck.
That means the upstream data layer has become performance infrastructure.
The storage layer also shapes the customer experience. If storage feels disconnected, complicated, or bolted on, customers notice. If it is native, branded, performant, and easy to consume, it strengthens the platform.
That is where B2 Neo comes in.
B2 Neo: Storage built to keep AI workloads moving
Backblaze B2 Neo gives platforms a high-throughput, white-label object storage backbone designed to support AI workloads at production scale.
It is S3-compatible, engineered for sustained throughput, and built to supply high-performance flash tiers without forcing providers to build and operate complex storage infrastructure in-house.
With B2 Neo, AI cloud platforms can offer object storage as a native extension of their own platform, including branded endpoints, partner-controlled pricing, and API-driven provisioning. That gives providers a new branded revenue stream while keeping the customer experience centered on their own platform.
B2 Neo also supports private connectivity options, helping create dedicated data paths that reduce shared network contention and improve predictability for demanding workloads. Backblaze has positioned the platform for high-throughput use cases, including up to 1Tbps aggregate throughput for AI and media workloads.
For platforms, that means storage becomes less of a build-vs-buy distraction and more of a platform advantage.
What AI clouds gain
When the data supply layer can keep up, GPU infrastructure becomes more effective.
Neocloud platforms can improve GPU utilization by reducing the time clusters spend waiting on data. AI teams can iterate faster because training runs and experiments move through the pipeline more efficiently. Platform performance becomes more predictable as datasets grow and clusters scale.
And operationally, neoclouds avoid the burden of building, scaling, and maintaining a large object storage system themselves.
That matters because every engineering cycle spent building commodity infrastructure is a cycle not spent improving the core compute platform, customer experience, orchestration layer, or AI-specific tooling.
The bottom line
AI clouds are winning because they give builders access to the compute resources they need. But compute alone is not enough.
A GPU cluster is only as useful as the data pipeline that keeps it fed.
As AI workloads scale, the storage layer becomes part of the performance story. The neoclouds that solve the data throughput problem will be better positioned to deliver consistent customer outcomes, improve GPU utilization, and turn storage into a native part of the platform experience.
GPU availability is only half the equation; Backblaze delivers the other half.Interested in learning how Backblaze supports AI cloud platforms? Explore B2 Neo or reach out to start a technical and strategic conversation.
Every computer vision model is a reflection of the data it was trained on. The precision of the labels, the consistency across annotators, the coverage of edge cases. Get the data right and the model performs. Get it wrong and no amount of architecture or compute will compensate.
AI-assisted annotation tools have made it possible to label at a speed and scale that was unthinkable a few years ago. Teams that used to spend weeks on manual labeling now generate annotations automatically and refine them. That acceleration opens up real opportunity, but it also raises the bar for the infrastructure underneath the annotation pipeline. The architecture needs to keep pace with the volume of data now moving through it.
We have spent the last decade building AI workflows and one pattern shows up consistently: the teams that treat annotation as infrastructure from day one outperform the ones that bolt it on later. The difference is not just tooling. It is the architectural decisions underneath, particularly around storage, that determine whether an annotation operation scales or stalls.
Annotation within the ML pipeline
A production ML pipeline spans data ingestion, preprocessing, training, serving, and monitoring. Annotation sits within the data layer, but it is the stage where several consequential storage decisions converge: how raw data is stored, who can access it, how long it is retained, and how it flows between labeling, training, and evaluation. Getting storage right at this layer strengthens every stage downstream.
Data gravity. A single autonomous driving project can produce terabytes of camera and LiDAR data before a single label is applied. This data needs to live somewhere durable and accessible before, during, and after annotation. It rarely moves once it lands.
Collaboration. Labeling teams may be internal, external, or a mix. Quality reviewers need the same data access as annotators. The data layer has to support concurrent access across roles and geographies without creating bottlenecks or redundant copies.
Lifecycle persistence. Labeled datasets are reused across training runs, refined as models improve, and versioned as labeling standards evolve. Storage needs to retain raw data alongside annotations for months or years.
Regulatory constraints. In healthcare, automotive, and defense, access controls around training data are subject to compliance requirements. Encryption, scoped credentials, and auditability are non-negotiable.
The teams that design for these requirements upfront build data operations that scale cleanly across the entire pipeline.
CVAT as the annotation layer
CVAT (Computer Vision Annotation Tool) started as an internal tool at Intel in 2017, was open sourced in 2018, and spun out as CVAT.ai Corporation in 2022. Millions of users use it today, and for good reason.
Annotation breadth. CVAT covers the full range of label types: bounding boxes, polygons, polylines, keypoints, skeletons, cuboids, brush-based masks, and tags. It handles images, video, and 3D point clouds natively, so teams working across object detection, segmentation, and pose estimation stay on one platform instead of stitching separate tools together.
AI-assisted labeling. Beyond SAM 3 and YOLO, CVAT supports custom models through its AI Agents framework, which lets teams plug their own inference endpoints directly into the labeling workflow. For video, SAM 2-powered tracking propagates annotations across frames. The shift from manual annotation to review-and-correct workflows is where the real throughput gains happen.
Deployment flexibility. CVAT ships in three editions: Community (free, self-hosted), Online (managed SaaS), and Enterprise (on-premises with SSO, RBAC, and audit logging). You can start hosted and move to self-hosted as data governance needs evolve.
Pipeline integration. CVAT exposes a REST API with a Python SDK and CLI, so annotation tasks can be created, populated, and exported programmatically. For teams building CI/CD-style retraining loops, this is what makes CVAT a pipeline component rather than a standalone manual step.
Backblaze B2: The storage layer that compounds
Annotation tools get the attention, but the storage layer is where the architecture compounds over time. CVAT supports native cloud storage integration through S3-compatible buckets, and Backblaze B2 fits directly into that connector. Configure your B2 endpoint, bucket name, and application key credentials, and CVAT treats it as native cloud storage.
This architecture decouples compute from storage. CVAT handles annotation logic while B2 owns durability and access, and you can scale, migrate, or replace either independently. Because B2 is S3-compatible, other stages of the ML pipeline, from training scripts to data validation to orchestration, access the same data directly from the same bucket CVAT writes to. No intermediate exports. No dataset copies drifting out of sync.
Retention is where the storage decision pays off most. Annotation datasets have long lifecycles, and footprints accumulate fast across concurrent projects. B2’s storage economics let teams hold large datasets across the full model development lifecycle without cost becoming the limiting factor. This is especially relevant for video-heavy projects and multi-sensor datasets where raw data runs into tens of terabytes.
Access control matters too. B2 application keys can be scoped to individual buckets or file prefixes with granular permissions and optional expiration, so access boundaries stay clean across annotators, labeling services, and downstream training pipelines. The CVAT integration guide for Backblaze B2 walks through the full setup, and the CVAT cloud storage documentation covers access permissions, manifest files, and endpoint routing.
Building the pipeline that scales into what’s next
The teams building the best computer vision models are not just choosing better algorithms. They are investing in the annotation infrastructure that feeds those algorithms: the right labeling platform, the right storage architecture, and the right cost structure to sustain it all as data grows.
This becomes even more critical as the field moves toward world models. NVIDIA’s Cosmos platform has already been downloaded over two million times. World Labs launched Marble for commercial 3D world generation. DeepMind’s Genie 3 produces interactive 3D environments in real time. Yann LeCun left Meta to start AMI Labs with the explicit goal of building AI systems that understand physics, not just predict text. These systems need training data that goes far beyond today’s labeled images: synchronized multi-sensor captures, physics-aware video, dense 3D point cloud annotations. The data volumes and annotation complexity will dwarf what most teams work with today, and the infrastructure underneath will need to handle it.
The annotation pipeline you build now is the one that will carry you into that future. Both layers are worth getting right early.
Ransomware and other disruptive attacks rarely succeed because of a single catastrophic failure. More often, they succeed because a system was designed for availability and scale, but not for persistent, adaptive adversaries testing for weak points from the outside.
For infrastructure and architecture leaders, that creates a practical challenge: how do you build systems that remain performant, cost-efficient, and operable while also standing up to attackers who are probing your environment for opportunities through traffic abuse, credential attacks, vulnerability exploitation, and social engineering?
The answer is not a single tool or framework. It is an architectural mindset: assume adversaries exist, assume controls will be tested, and design systems that continue operating safely under pressure.
Security starts with architecture, not alerts
One of the most common mistakes organizations make is treating security as something layered onto infrastructure after it is built. In practice, resilience comes from decisions made much earlier:
How traffic is handled under stress.
How systems and services are segmented.
How identity and access are enforced.
How quickly vulnerabilities are surfaced and validated.
How failure is contained when something goes wrong.
This is what separates reactive security from resilient architecture. The strongest environments are not the ones with the most dashboards; they are the ones built so that no single weakness can easily cascade into a broader incident.
Designing the perimeter to buy time, not perfection
Even in a world shaped by zero trust, the perimeter still matters, especially for availability.
Large-scale traffic floods, automated scanning, and API abuse are often the opening move. These events may not be the full attack, but they can create noise, consume resources, and open the door for more targeted follow-on activity. Infrastructure teams need defenses that can:
Absorb unexpected traffic without cascading failures
Distinguish abusive patterns from legitimate use
Prevent noisy attacks from turning into operational incidents
These defenses can never provide perfect prevention; cybercriminals can attack with too much sophistication and velocity. Rather, the goal is resilience. Good perimeter design buys time, preserves service availability, and prevents external pressure from becoming internal disruption.
Modern environments change too quickly for occasional reviews to be enough.
Attackers do not work on quarterly schedules, and neither should defensive programs. A stronger model is continuous vulnerability discovery: using multiple signals to understand what is exposed, what is exploitable, and what actually matters.
That can include a mix of:
Threat intelligence on active exploitation trends
External research programs such as bug bounties
Regular penetration testing
Internal testing and automated vulnerability scanning
Each of these presents different types of risk. Together, they reduce blind spots and help teams prioritize fixes based on real-world likelihood and impact, not just severity scores on paper.
Limiting blast radius is an architectural responsibility
A useful security question is not only “How do we stop every attack?” but also “What happens if one control fails?”
That shift changes how teams think about system design. It places greater emphasis on:
Hardening critical systems
Enforcing strict access controls
Separating environments and services
Reducing unnecessary trust relationships
Containing failure before it spreads
This is where architecture has an outsized role. Detection matters, but containment matters just as much. Systems built with clear boundaries are easier to defend and easier to recover operationally when incidents happen.
Identity is part of infrastructure
Many attacks do not begin with sophisticated exploits. They begin with compromised credentials, reused passwords, phishing, or other attempts to gain access through people rather than code.
That is why identity should be treated as a core infrastructure layer, not a separate administrative concern.
Strong identity practices often include:
Long, high-entropy passwords
Multi-factor authentication
Checks for compromised credentials
Clear access policies tied to real job needs
These controls reflect a simple truth: humans are part of the system. Security controls need to be strong enough to resist abuse and usable enough to work at scale.
Security as a system, not a checklist
No single control creates resilience on its own.
What matters is how controls reinforce one another: how traffic protections support availability, how vulnerability discovery informs remediation, how segmentation reduces impact, and how identity controls protect critical paths.
For infrastructure and architecture leaders, the takeaway is straightforward: the most resilient systems are not built on assumptions of safety. They are built on the expectation that adversaries will look for openings and that defenses need to hold up under real pressure.
That is why security works best as an architectural decision, not just an operational one.
A practical Backblaze perspective
At Backblaze, this is the lens we use when thinking about protection against bad actors: not as a single feature or isolated control, but as a layered systems problem that spans network protections, vulnerability discovery, access controls, and operational resilience. The important point is not any one safeguard in isolation. It is the way those safeguards work together so that a single weakness is less likely to become a customer-impacting event.
Download the ebook on building an affordable, resilient disaster recovery strategy that matters when ransomware strikes.
Welcome to our second quarterly Network Stats report covering Q1 of 2026. Along with Drive Stats and Performance Stats, Network Stats pulls back the curtain on real-world infrastructure data, particularly how network-level analytics reflect emerging AI industry trends and usage patterns.
Get more Network Stats (and the details of the dataset)
If you are curious about what metrics we’re recording and how we classify data in this series, check out the details outlined in our Q3 2025 Network Stats and Q4 2025 Network Stats report.
One of the roles of the Network Engineering (NetEng) team at Backblaze is to monitor how traffic moves into, out of, and across our platform—not just day-to-day, but over time as customer behavior and industry dynamics evolve. Right now, few forces are reshaping networks faster than AI.
With the launch of B2 Overdrive in April 2025, we built a direct, high-performance path between our storage layers and neoclouds where processing, inference, and modeling take place. It has given us a front-row seat to the impact of AI and how network behavior is changing with it. This quarter, in addition to our regular data analysis, we’ve added some geographic heatmaps to understand where and how data is moving.
Join us live for the webinar
Join us live for the Q1 2026 Network Stats webinarMonday, May 4, 2026 at 11:30 a.m. PT / 2:30 p.m. PT. We’ll explore where AI traffic concentrates, how high-magnitude data flows behave, and what early indicators suggest about the future of AI-native infrastructure design.
Can’t make it live, or reading this article after-the-fact? Sign up anyway and catch the recording on demand.
AI: The elephant in the room
AI workflows don’t just need a place to store data, they need to be able to move it quickly, easily, and nearly constantly for short bursts. Large, multi-petabyte datasets are ingested, transformed, exported for training, pulled back for evaluation, and periodically refreshed as models evolve.
Backblaze plays a key role at both ends of that lifecycle. We serve as a durable storage layer for the initial data ingestion, and as the high-throughput source feeding model training, evaluation, and validation to whatever best neocloud is suitable at the moment. Once that model has been trained, it needs to be stored, served, and periodically retrained, where we serve as the storage medium.
From a network perspective, this represents a meaningful shift from diffuse, internet-style traffic patterns to large, high-bandwidth flows between a smaller set of endpoints typical of AI-centric infrastructure.
Trends and spring renewal
The defining theme of the quarter is “winter freeze” as we observed what looks to be a quiet period of Neocloud and hyperscaler traffic over the winter months with an uptick in March.
The stacked area graph below shows total traffic by network type over time updated with the most current data. Hosting and internet service provider (ISP) traffic stayed largely within historical norms reflecting steady-state usage patterns. Three slices stand out this quarter:
CDN traffic: Increase in CDN traffic over the winter months.
Neocloud traffic: After the October 2025 peak, we saw a decline in neocloud traffic heading into January. The winter months were a low volume period with an upward trend observed February into March 2026.
Hyperscaler traffic: Hyperscaler traffic also followed the Neocloud pattern of a low period during winter with an upward trend in March 2026.
Monthly view of all bits transferred to each network type (2025-05 to current)
With more than three quarters of data at our disposal, we can now start to see some trends over time. What do we think is happening?
This could be an indication of the human element where the business cycle has a lot of downtime in the winter months—all of our code, infrastructure, computing jobs, and new innovations involve people somewhere along the chain and we all (hopefully) tend to take more time off in the winter months.
Another hypothesis is that our numbers only show bits transferred over our network links over time. If a large dataset has been stored with us, there may not need to be an update to the large stored dataset for a number of months as code and models are refined, and then suddenly a large amount of new data makes its way over our network links. Perhaps a combination of both—human and training lifecycle?
We’ll be tracking these metrics and updating in future reports, so this high-level view of network traffic segmented by network type will be interesting to watch.
Chart overview
Now let’s take a deep dive into our data and answer these questions:
Quarter over quarter heatmaps: How and where data moves
To better understand our network activity, we isolated variables like region and types of provider. Let’s look at the following dimensions:
Total traffic volume: Where did we send and receive the most traffic?
Magnitude: Where were the data transfers with the most bits per unique IP address?
Uniqueness: What does the number of distinct IP addresses look like?
Quick terminology refresher
Regions
US-West: Our largest and longest-running region
US-East: Region with the most observed proximity to neocloud infrastructure
CA-East: Our newest region in Canada.
Network Types
CDN: Networks that use Backblaze as an origin store for content delivery
Hosting: Traditional hosting providers that runs workloads like physical or virtual servers for web, database, or application tasks
Hyperscaler: Large, traditional cloud providers
ISP Regional: Local or regional ISPs, think of these as the “last mile” paths as these networks are very close to customer equipment and efficient
ISP Tier1: National or international ISPs that carry our traffic long distances
Neocloud: AI -focused compute networks
Heatmap #1: Where did we send and receive the most traffic?
US-West ISP-Regional traffic continues to be a hotspot on the heatmap, as expected. This region has the largest footprint behind it and connections to internet exchanges (IX). This quarter, with a lull in neocloud and hyperscaler traffic over the winter period, we saw an increase in traffic to our CDN partners. The amount of traffic to CDN networks in the US-West, US-East, and EU-Central regions all increased quarter over quarter.
Total number of bits transferred across our regions to each network type for Q1 2026.
Total number of bits transferred across our regions to each network type in Q4 2025.
Heatmap #2: Where were the data transfers with the most magnitude (bits per IP address)?
Another metric we record is bits per IP or what we term “magnitude.” This combination of the amount of traffic transferred with how many actors are involved per network is a good proxy to measure how heavy or impactful individual data flows are. In short:
High volume, many IPs: Easier to distribute and load-balance across infrastructure. And many source and destination pairs means that we can traffic engineer at the WAN layer, sending some traffic over one provider and some over another.
High volume, few IPs: More difficult, but more interesting, from a NetEng perspective.
Despite the total amount of traffic decreasing over the winter months for neocloud traffic, the magnitude of neocloud transfers still remains high. This speaks to the nature of the traffic pattern—when a GPU/compute cluster is ingesting or producing data, it does so at a high bitrate with just a few number of unique endpoints talking to each other.
As expected, the concentration of our magnitude metric is high for our US-East cluster, with an uptick in concentration in US-West and EU-Central. Where specifically is this new concentration in these regions? Spoiler: We explore neocloud traffic later in the report with geographical data!
Magnitude transferred across our regions to each network type for Q1 2026.
Magnitude transferred across our regions to each network type for Q4 2025.
As with last quarter, we see a high concentration of neoclouds in US-East, but our new heatmap also shows a rising activity in US-West and EU-Central. We also see more distribution in other use cases.
Heatmap #3: How many unique addresses do we interact with?
Uniqueness—measured by the number of distinct IP addresses per network type—adds another dimension to the story. Unsurprisingly, the quarter over quarter heatmap looks almost identical. This is expected with our US-West region being the most mature and serving a large amount of ISP Regional consumers and is a good sanity check on our dataset.
US-West shows the highest overall uniqueness, driven by its larger number of data centers and mix of workloads.
Neocloud traffic, by contrast, tends to involve fewer, more persistent endpoints, consistent with AI pipelines that rely on stable, long-standing connections between storage and compute.
This is where we can clearly see those AI networking elephant flows showing up in the data.
Communication uniqueness across our regions to each network type for Q1 2026.
Communication uniqueness across our regions to each network type for Q4 2025.
Summary: Seasonal change in traffic flows
With a lull in bits transferred as noted in our top level graph, we can see what other networks by percentage took over. CDN traffic increased from around 20% to 32% of our total traffic, localized ISP regional traffic also increased 21.5% to 27.8%. Neocloud and hyperscaler traffic reduced from 36.4% in Q4 2025 to 25.5% in Q1 2026.
Quarter over quarter data
We’re tracking our usual metrics here, and we gave you both this quarter and last quarter’s charts so you can easily spot potential trends.
First let’s take a look at where all our traffic goes from a global perspective with an updated view of last quarter.
A Sankey diagram of all ingress and egress traffic grouped by type of network for Q1 2026.
A Sankey diagram of all ingress and egress traffic grouped by type of network for Q4 2025.
Next, let’s take a look at the geography of our network traffic. As we’ve already seen in previous heatmaps, data gravity is concentrating traffic into specific locations.
Where in the world is the neocloud?
New for March 2026, we’ve added geographic information to our dataset, allowing us to take a look at the concentration of traffic based on network types. We’re taking a look into the following locational slices:
Countries
Countries excluding the United States
U.S. states
Heatmap #1: What countries show the highest concentration of traffic by network type?
Neocloud, hyperscaler, and CDN traffic in our dataset all show high concentrations in the United States. Is this due to our US-West and US-East regions being the largest of our deployments or is it related to how certain traffic types are present in the emerging AI market? A quick search shows that the U.S. contains around 40-45% of all data centers globally, so it’s likely the sheer deployment size and scope of US sites aligns with what we’re seeing at the network level.
Total number of bits transferred by network type to countries from March 2026.
That said, excluding outliers can show us additional geographic trends, which leads to our next heatmap.
Heatmap #2: If we exclude the U.S., what countries show the highest concentration of traffic by network type?
Since the United States numbers highly skew the heatmap concentration, below is a heatmap without the US to give us better fidelity on ex-US datapoints. Interesting to note that we deliver a large amount of traffic to CDN entities in the Netherlands. This is due in part to our connectivity to AMS-IX (Amsterdam Internet Exchange).
The network posture of Europe differs from the United States to where local IX networks are preferred over larger Tier1 ISP networks for transit (politically, cost, and preference wise). Second up is Singapore for CDN content and hosting activity in Germany. The next standout is a concentration of neocloud related activity in Finland, Brazil, France, and Canada.
Total number of bits transferred by network type to countries, excluding the United States, from March 2026.
Heatmap #3: What U.S. States show the highest concentration of traffic by network type?
If we dive into just the U.S. States, we can see the heavily weighted concentration of neocloud traffic to and from California. Hyperscaler activity matching up with our expectations as California and Virginia (specifically the Ashburn and Reston corridor) have a high concentration of partner networks. CDN traffic for us concentrates more for Backblaze specifically since the US-West region is our largest cluster footprint and longest running sites, so naturally the data being served out of these sites is more long-lived content lifecycle wise.
Total number of bits transferred by network type to US States from March 2026.
These insights into data geography help us understand, plan, and modify our growth trajectory. I say “help,” because we’re also discovering that neocloud and hyperscaler activity is very bursty and has a high magnitude of traffic flow below. From a planning perspective, understanding whether those bursts translate to a higher baseline for increased demand—and how to support bursts when they happen—is a different conversation than the predictable network trends of years past.
Neocloud and hyperscaler traffic vs predictive patterns
This quarter we’re sharing a deeper dive into the metrics associated with neocloud and hyperscalers over time. These two traffic types are driving innovation at Backblaze and are interesting to share to the larger industry. While CDN, hosting, and ISP regional traffic patterns are easy for us to model and account for as we manage our network infrastructure, neocloud and hyperscalers growth profiling are a challenge! As we said above, they are bursty and have a high magnitude (bits per associated IP address).
And, in the spirit of that conversation, we have several new views to share:
Neocloud and hyperscaler magnitude (bits per IP address) over time
Heatmaps over time
Neocloud
Hyperscaler
CDN
Hosting
ISP regional
Chart #1: What’s the magnitude of neocloud and hyperscaler traffic over time?
Matching our earlier charts, we saw a burst of activity from August to December of last year with a resurgence of high magnitude neocloud traffic in March of 2026.
Magnitude of neocloud and hyperscaler related traffic over time.
Heatmap #1 and #2: How dynamic are neocloud and hyperscaler traffic patterns?
Neocloud and hyperscaler traffic patterns are the most impactful to our operations due to the magnitude of their data flows. Below is a more detailed look at these concentrations over time, with a burst of activity from August to November for Neoclouds, a quiet period over the winter months, and a pickup again in March.
As expected our US-East region remains a hotspot of Neocloud related activity. One standout from this analysis is that the Neocloud activity in March is more spread out over our US-West, US-East, and EU-Central regions. It will be interesting to see if this spread grows or contracts over time.
Neocloud monthly traffic totals by region for May 2025–March 2026.
Over the winter months, there was a noticeable decrease in activity for hyperscale related traffic, most notable in January, but when compared to neocloud traffic, the month-over-month traffic patterns remained strongly visible in our US-East region.
Hyperscaler monthly traffic totals by region for May 2025–March 2026.
Heatmap #3, #4, and #5: How dynamic are CDN, hosting, and ISP regional traffic patterns?
We’re grouping CDN, hosting, and ISP regional types together because they represent a “steady-state” for us as network operators. These patterns are predictable, spread out over time, and generally do not change month-to-month. We do see visible bursts of traffic, like with a heavy blue tile for CDN in September and a few areas of hosting related traffic in May and October of 2025, but overall these are less impactful to our operations because the magnitude (bits per unique IP address) is lower—many sources are talking to many destinations, which as operators is easy to load balance.
CDN monthly traffic totals by region from May 2025–March 2026.
Hosting monthly traffic totals by region for March 2025–May 2026.
ISP Regional monthly traffic totals by region for March 2025–May 2026.
The most striking example of this predictability is, unsurprisingly, ISP regional traffic. This represents your more consumer driven workflows and use cases.
Neocloud business cycle and geography
We can draw a conclusion from all these charts: neocloud and hyperscaler are both different traffic patterns and far more dynamic than CDN, hosting, and ISP regional traffic. For our Network Engineering group, this means we have two different stylistic approaches towards managing our network.
First, when planning for the neocloud and hyperscaler traffic, our solutions entail adding large amounts of additional bandwidth in increments of 100G and often 400G ports to handle burst rates, ensuring that our inter-switch links inside our datacenter can also handle bursts of traffic, and reaching out to select partners to establish private network-to-network interface (PNI) connections where appropriate for zero-settlement transit.
Our steady state growth patterns stem from CDN, hosting, and ISP regional traffic with easy to model growth curves. Looking over monthly numbers indicates a clear pattern for us, and that’s easy to plan for.
The last factor that we’re placing more emphasis on is the geographical location of our network interconnections. We’re seeing a high concentration of demand located in the United States, specifically in regions like California, Virginia, Illinois, and Georgia.
With more datapoints, we can clearly see the magnitude of the neocloud and hyperscaler transfers when compared to other network types. As above, it’s a bit early to claim concrete quarter over quarter patterns, but we’ll keep monitoring and updating the dataset.
What’s next?
Anything specific you want to see? Let us know in the comments or reach out to the Network Stats team. Or, keep up-to-date with the latest technical content with our Developer Newsletter.
NAB Show 2026 wrapped up last week in Las Vegas, and we left with something special in hand: the NAB Show Product of the Year Award in the Cloud Computing and Storage category—this time for Backblaze B2 Neo.
It’s a meaningful recognition, and one that reflects where we see the media and AI infrastructure market heading. Here’s a look at what the recognition means, and why B2 Neo matters.
What this recognition means
Winning the NAB Product of the Year Award reflects something we genuinely believe: that storage infrastructure is a foundational capability for modern media and AI platforms, not an afterthought or a separate vendor relationship to manage.
The NAB Show brings together the best of the media and entertainment industry, and having B2 Neo recognized in this context—among platforms solving real, production-scale problems across streaming, OTT, AI-driven media processing, and large-scale content delivery—is meaningful validation that the approach resonates.
B2 Neo launched in February 2026 and is already supporting production workloads including AI training pipelines, high-performance computing environments, and large-scale media delivery. The response from platform providers has reinforced what we know: organizations want to offer integrated, high-performance storage without building it from scratch, and they want the economics to make sense.
What is B2 Neo?
B2 Neo is a high-performance, S3-compatible cloud object storage solution purpose-built for platforms running data-intensive media and AI workloads. But describing it simply as “cloud storage” undersells the point.
The key distinction: B2 Neo is a white-label service. Rather than selling storage directly to end users, B2 Neo enables platform providers—like media workflow vendors—to offer fully integrated storage under their own brand. Partners launch their own storage service with custom endpoints, pricing, and user experiences, without having to build or operate the underlying infrastructure themselves.
The result is that platforms can go from “we don’t offer storage” to “we have a native, high-performance storage tier” in weeks rather than years, with none of the capital investment or engineering overhead that building it in-house would require.
Why it was built
The problem B2 Neo addresses has been growing for years, but it’s become acute as streaming, OTT, and AI-driven media workflows scale up.
Compute has gotten fast, distributed, and relatively affordable. GPU clusters, edge networks, and CDNs can all handle increasingly complex workloads. But storage has often lagged behind—fragmented across providers, expensive to move data in and out of, and either too costly or too operationally burdensome to build in-house.
The consequence is real: GPU clusters sit idle waiting on data. Streaming pipelines bottleneck on access speeds. Media organizations duplicate content across storage systems because no single layer integrates cleanly into the rest of the stack.
B2 Neo was designed to remove that bottleneck. It delivers up to 1Tbps of throughput to ensure that compute resources—GPU clusters, streaming systems, edge delivery networks—are never waiting on storage. It combines that performance with Backblaze’s 17+ years of operational experience at exabyte scale, and wraps it in an API-first architecture that plugs directly into partner platforms.
How it works
From a technical standpoint, B2 Neo delivers high aggregate throughput using cost-efficient, disk-based infrastructure with strategically deployed flash layers—a write-through cache design that captures the performance benefits of flash without the cost and scalability limitations that come with an all-flash architecture at the multi-petabyte scale that media and AI workloads require.
For workloads where throughput matters as much as latency—moving large video files, training AI models, serving content at scale—this approach is particularly effective. It allows platforms to maintain a centralized data repository and efficiently deliver data to compute providers, edge networks, and CDNs without duplicating data across storage systems.
API-driven provisioning lets partners programmatically create and manage storage accounts, permissions, and billing within their existing systems. Whether a partner is running an OTT platform, a media asset management system, or an AI training pipeline, B2 Neo integrates as a native extension of that environment rather than an external dependency to work around.
Included egress and free API calls round out the picture, eliminating the usage-based fees that typically make storage decisions financially complicated.
What’s next
This is a product that will keep evolving alongside the media and AI infrastructure landscape. We’re working closely with early partners to expand B2 Neo’s capabilities—performance, integration depth, provisioning flexibility—and we’ll have more to share as those conversations develop.
If you’re building or operating a platform that would benefit from embedded, high-performance storage, we’d love to talk. Reach out to our team to learn more about what a B2 Neo partnership looks like.
Bandwidth purchased for data center connectivity surged by nearly 330% between 2020 and 2024, driven primarily by AI workloads. And in 2024, just 10 buyers accounted for nearly 62% of all purchases, according to Zayo’s Bandwidth Report. That concentration is a structural feature of how AI moves data.
Every training run that pulls data from Backblaze storage to a neocloud passes through our network, and our telemetry captures what those flows look like in real time. Our Q4 2025 Network Stats report covers a full quarter of that data. It shows AI workloads producing a distinct network signature: sustained, high-volume transfers between a small number of endpoints, with infrastructure requirements specific enough to be worth examining in detail.
This piece walks through what that signature looks like and what it means for the infrastructure decisions teams are making right now.
The AI model lifecycle and how it moves data
AI model development is a cycle. Large datasets are ingested and consolidated, exported to compute for training, pulled back for evaluation, then pushed out again as models are refined, retrained, and updated with new data. Each stage requires moving substantial volumes of data between storage and compute, repeatedly, over the life of a model.
That structure produces a specific kind of network traffic. AI training moves petabyte-scale data between storage and compute nodes in sustained, long-lived flows—what network engineers call elephant flows—with training jobs running for hours or days under continuous network load. Add frequent checkpointing, model updates, and periodic data refreshes, and the result is traffic that is high in volume and persistent across the entire training run.
This shows up clearly in the Q4 2025 Network Stats data. Neocloud traffic spiked sharply from July through November, peaking in October, then settled into a higher baseline heading into the new year. One interpretation of that shape is the AI lifecycle playing out across a concentration of large training cycles: ingestion, training egress, then a new steady state as stored models get served and periodically retrained. As we accumulate more quarters of data across a broader customer mix, we’ll be better positioned to distinguish that pattern from seasonal budget cycles or customer-specific factors.
Backblaze network traffic for Q4 2025.
Also visible in the Q4 data is where this traffic is going. Cloud-to-cloud traffic grew from 36.2% to 49.6% quarter-over-quarter, with hyperscaler destinations rising from 3.5% to 18%. As the report notes, it’s too early to call these statistically significant trends; the dataset reflects Backblaze’s specific customer mix and covers a single quarter. The direction is consistent with how AI teams operate in practice: moving workloads across neoclouds and hyperscalers depending on price, availability, and job requirements. The storage layer is what persists across those compute environments, which has direct implications for how it needs to be designed.
What elephant flows require from a network
Traditional cloud infrastructure is designed around a specific traffic profile: many clients, many sessions, many discrete transactions. Routing, load balancing, and edge capacity are all optimized for that pattern, distributing load broadly and handling high volumes of short-lived connections efficiently.
Elephant flows don’t fit that profile. AI training establishes persistent, high-volume connections between client and storage that sustain continuous data movement for hours or days at a time. These connections are stickier than typical cloud traffic, particularly on peered networks, and the strain they produce is concentrated rather than distributed—showing up primarily at the edge, where routers handle sustained throughput at scale. Most traditional cloud infrastructure wasn’t provisioned for that kind of sustained pressure at the edge, because most workloads don’t produce it. Internal to the network, depending on a myriad of things—object size, concurrent threads, hardware, internal routing logic—your network path being sticky doesn’t reduce the number of I/O operations for servers, and often that becomes one of the biggest bottlenecks.
The stakes make this consequential. Training the most advanced models now costs hundreds of millions of dollars, according to Epoch AI—though we also know this is a new technology, and therefore likely the compute will get more efficient over time. That said, the storage is still storage: Data has to live somewhere.
Infrastructure that can’t sustain throughput under continuous load doesn’t just slow training down; it adds cost to every run. The practical answer is building throughput capacity at the connection points between storage infrastructure and the internet or peer network, sized for sustained flows rather than peak bursts.
That’s what AI-grade storage infrastructure is designed around: sustained throughput to a small number of destinations, at 100Gbps to 1Tbps per transfer for the largest AI workflows. Achieving that in practice means rethinking how a network is designed, routed, and scaled. We’ve written separately about what that looked like for Backblaze’s own infrastructure. Latency matters here for a specific reason: on long-distance transfers, higher latency directly limits achievable sustained throughput, which is one reason why geographic proximity to compute infrastructure affects real-world performance.
The Q4 Network Stats heatmaps show this pattern from two angles. The magnitude heatmap, measuring bits transferred per unique IP address, shows high-magnitude neocloud flows clustering clearly in regions serving AI-heavy compute endpoints. The uniqueness heatmap shows neocloud traffic involving fewer, more persistent endpoints than CDN or ISP traffic, consistent with AI pipelines that rely on stable, long-standing connections between storage and compute.
The geography of AI infrastructure
The heatmaps show where AI traffic concentrates geographically today. Neocloud activity in the Q4 dataset clusters in Chicago, Dallas-Houston, Denver, New York, the Northern Virginia Reston/Ashburn corridor, and Atlanta, with a clear skew toward the East Coast. This reflects where AI compute infrastructure was built first and remains densest. Keeping latency low between storage and compute is a prerequisite for sustaining the high throughput rates AI workflows require, and that constraint has historically made East Coast proximity an advantage.
Magnitude transferred across our regions to each network type in Q4 2025.
That concentration is consistent with broader infrastructure dynamics. AI training workloads are driving demand for regions with available power, fiber density, and compute infrastructure, and power constraints in preferred markets are already forcing operators to explore secondary locations and invest in custom power infrastructure. Demand in markets outside traditional data center hubs is growing rapidly as a result: Metro bandwidth in Memphis grew from 0.3 terabits to 13.2 terabits between 2023 and 2024. On the flip side, building out cabling to those traditionally under-utilized locations is expensive, often adding thousands of dollars per month to data center economics. High-capacity interconnects are central to making those secondary locations viable; without them, the compute investment is stranded.
The scale of what’s being built reflects the trajectory of the workload. AI training infrastructure is projected to grow at a 22% compound annual growth rate (CAGR) through 2030, reaching more than 60GW of capacity, while inference infrastructure is expected to grow faster still at 35% CAGR, reaching more than 90GW, according to McKinsey. Training and inference have different geographic requirements: training tolerates latency and can sit in power-rich remote locations, while inference needs to be close to users, which means the buildout will be distributed across both dense metro markets and secondary locations connected by high-capacity fiber.
Backblaze’s own infrastructure decisions reflect this pattern directly. The East Coast concentration drove the decision to double Backblaze’s US-East footprint. At 100Gbps and above, proximity to where AI compute is actually running is a determining factor in storage performance.
What AI-ready storage infrastructure actually means
Storage has traditionally been sized for capacity and evaluated on cost per terabyte. AI workflows change the calculus. When a training run is pulling petabytes of data from object storage to flash storage at sustained 100Gbps rates, the storage layer is as much a performance determinant as the compute layer. A storage system that can’t sustain those throughput rates creates a bottleneck that no amount of GPU capacity can compensate for.
Throughput capability is one requirement. Portability is the other. The multi-cloud behavior visible in the Q4 data reflects how AI teams actually operate: moving workloads to whichever compute provider offers the best price-performance for a given job. Storage that is tightly coupled to one cloud provider is structurally incompatible with that workflow. Data that can’t move freely across cloud environments becomes a constraint on the model development process.
This is the infrastructure problem Backblaze B2 Overdrive is designed to address. By building a direct, high-performance path between Backblaze’s storage layer and the neoclouds where AI processing takes place, it provides the sustained throughput that training workflows require alongside the portability to move data as compute requirements change. The connections between Backblaze and neocloud endpoints visible in the Q4 heatmaps represent that architecture in practice.
The point extends beyond any single product. As AI workloads become a larger share of overall data center activity, the criteria for evaluating storage infrastructure are shifting. Capacity and cost per terabyte remain relevant, but sustained throughput capability, interoperability with compute providers, and network proximity to AI infrastructure are becoming equally important factors. Teams that treat storage as a passive component in AI pipeline design are likely to find it becomes the active constraint.
Early signal, long trend
The Q4 2025 Network Stats data is one quarter of observations from one storage provider’s network. The patterns it shows—high-magnitude flows to a small number of endpoints, East Coast geographic concentration, rising cloud-to-cloud traffic, a higher baseline heading into the new year—are consistent with what the broader industry understands about how AI moves data. What’s new is that they’re visible in real network telemetry rather than modeled projections.
We’ll be watching how neocloud traffic concentration evolves regionally, how the training-to-inference ratio shifts as inference infrastructure scales, and whether the cloud-to-cloud growth visible this quarter continues.
The full dataset, methodology, and visualizations are in the Q4 2025 Network Stats report. For background on how we classify and measure network traffic, the Q3 2025 report covers the dataset in detail, and you can follow the whole series here.
Modern media workflows don’t run on storage alone. They run on ecosystems—tightly integrated stacks of tools that ingest, process, analyze, move, review, and distribute content at scale. The companies we partner with aren’t just integrating with Backblaze; they’re building on it to solve real, specific problems that media teams face every day: archives that are impossible to search, file transfers that collapse over distance, review cycles that slow production to a crawl, compliance workflows that can’t keep up with library growth.
At NAB Show 2026, we’re bringing ten of those partners into booth N1259 to share what they’ve built. But the stories they’re telling aren’t just for Las Vegas—they’re for any media team trying to understand what a modern, cost-efficient, deeply integrated workflow actually looks like in practice.
Here’s a look at each partner, the problem they solve, and why it matters.
Imaginario AI: From Archive to Action
Presenter: Jose Puga, CEO and Co-Founder, Imaginario AI
Most video archives are passive. Content sits in storage, cataloged by someone who had time to do it years ago, effectively invisible to the people who could use it today. Imaginario AI flips that model.
Jose Puga’s session, “From Archive to Action: How AI Is Turning Your Video Library Into a Revenue Engine,” frames the shift from passive storage and cataloging to intelligent systems that actively surface, repurpose, and monetize content. The talk covers how marketing teams can accelerate campaigns, post-production teams can shortcut assembly, and compliance workflows can move from reactive to automated.
Imaginario is a multimodal video agentic platform that understands video in a human-like way—recognizing sounds, speech, and visual scenes without requiring time-based metadata. The platform is trusted by Warner Bros. Discovery, Sony Music, and Universal Pictures, and has won back-to-back IBC Best of Show honors in 2024 and 2025.
The Backblaze integration means content stays where it lives—no migration, no friction. As Jose puts it: “Backblaze provides our clients a scalable, reliable cloud layer that eliminates the friction of manual data transfers. Our native integration saves video teams dozens of hours by keeping content on Backblaze while unlocking high-speed AI analysis, retrieval, and repurposing in media and entertainment.”
Suite Studios: S3 Native File Streaming
Presenter: Jay Maxwell, Co-Founder & CPO, Suite Studios
Remote and distributed production teams have wrestled with the same problem for years: How do you collaborate on large media files when your team is spread across the globe? Suite’s answer is S3 Native File Streaming on Backblaze B2. The stack makes working with cloud object storage all-around easier, enabling teams to read and write data as standard objects without copying, syncing, or transferring.
Jay Maxwell’s session explores how global teams can instantly access and collaborate on large media files from anywhere—eliminating delays and accelerating production timelines. No syncing, no waiting, no workarounds. Just files that behave the way you need them to, wherever your team happens to be.
TwelveLabs: Unlocking Archive Value with Video AI
Presenter: Jordan Woods, Senior Solutions Architect, TwelveLabs
There’s a pattern across media organizations of all sizes: years of valuable archived content sitting effectively invisible because manual cataloging doesn’t scale. TwelveLabs makes that content searchable and monetizable.
Jordan Woods’ session, “Unlocking Archive Value with TwelveLabs Video Intelligence,” shows how pairing Backblaze’s cost-efficient storage with TwelveLabs’ video AI gives organizations a practical path to turn dormant archives into searchable, monetizable assets.
As Danny Nicolopoulos, Head of Strategic Partnerships at TwelveLabs, explains: “Media companies are sitting on years of valuable archived content that’s effectively invisible because manual cataloging doesn’t scale. Pairing Backblaze’s cost-efficient storage with TwelveLabs’ video AI gives organizations a practical path to turn those dormant archives into searchable, monetizable assets.”
Tillered: Full Speed Cloud Storage Over Any Distance
Presenters: Davey Goode, Founder & Stephen Ceci, Commercial Lead, Tillered
Physics is an undefeated opponent. Move data over long distances and throughput drops—no matter how fast your storage is or how much bandwidth you have. Tillered is built to remove that distance penalty.
The session, “Backblaze B2 Accelerate with Tillered: Full Speed Cloud Storage Over Any Distance,” demonstrates how the B2 Accelerate product brings Tillered’s acceleration technology to Backblaze B2, with transfers up to 34x faster as a result. No simulations—just live transfers with real results, showing what it looks like when enterprises can move data across any distance without adding bandwidth or changing workflows.
Davey Goode founded Tillered after repeatedly running into the same issue building large-scale connectivity infrastructure: No matter how much bandwidth was available, performance collapsed over distance. This session is the solution he built.
Telestream UP.Review: Decide Faster
Presenter: Sebastian Manemann, Senior Director of Product Management, Telestream
Capture, storage, and distribution have gotten faster. Review hasn’t kept up. Proxies, downloads, duplicated files—the approval workflow often undoes the speed gains made everywhere else in the pipeline.
Sebastian Manemann’s session, “Decide Faster: Real-Time Review, QC, and Delivery with Telestream UP.Review and Backblaze B2,” demos how Telestream UP.Review enables real-time, high-resolution playback and QC directly on media stored in Backblaze B2 without moving or duplicating files.
By keeping content in Backblaze as the central storage layer, teams can review instantly, validate quality, and move to delivery faster—all while maintaining a single source of truth across the workflow. As Sebastian frames it: “When you eliminate duplication and review directly from storage, you don’t just move faster—you operate smarter.”
Qencode + Sardius: A Multi-Vendor M&E Workflow in Practice
Presenters: Murad Mordukhay, CEO, Qencode, and Jason Shore & Ari Burt, Sardius Media
This one is different from the others—it’s not a product demo; it’s a case study. Sardius Media rebuilt their media pipeline around a race model: Multiple storage providers write in parallel, and the fastest result wins.
The session breaks down how Backblaze wins approximately 80% of those races, with Qencode orchestrating the encoding layer across the pipeline. It covers what the production data actually shows, and what Sardius would do differently if they were designing the workflow from scratch today.
Qencode uses machine learning to reduce file sizes by an average of 60% without sacrificing quality. Their CEO, Murad Mordukhay, sums up the partnership plainly: “The best partnerships are when two companies solve different halves of the same problem. Backblaze handles storage with the kind of reliability and transparency that perfectly aligns with how we think about transcoding. No surprises, no lock-in, just infrastructure that earns trust by performing every single day.”
Media workflows break down not just because of bad tools, but because of coordination failures between good ones. Files don’t sync. Teams duplicate work. Availability lags behind where content actually needs to be.
Christoph Jurkuhn’s session, “The Hidden Layer: Orchestrating Media Across the Stack with HiScale and Backblaze,” shows in a live demo how HiScale orchestrates media movement across distributed environments while Backblaze B2 provides the durable, scalable storage layer underneath. Files move, sync, and become available across teams and tools without delays, duplication, or manual intervention.
“Backblaze is built for straightforward, cost-efficient storage and HiScale builds on top of that to orchestrate and process your media. It’s a natural fit for modern media workflows.”
Iconik: Control Your Content
Presenter: Jeremy Strootman, Media Workflow Consultant, Iconik
At a certain scale, the problem isn’t creating content; it’s controlling it. Files get lost, search slows to a crawl, and archives become liabilities instead of assets.
Jeremy Strootman’s session, “Control Your Content: Turning Media Chaos into Operational Advantage,” demos how Iconik and Backblaze B2 give teams operational control over their media: making content instantly searchable, accessible, and reusable across the entire workflow.
With a foundational background in storage and archiving, Jeremy has spent over two decades helping content creators maximize efficiency and productivity across the entire media lifecycle, from ingest to archive. His perspective: “Backblaze gives us the scalable foundation; Iconik gives teams control over how that content is actually used.”
ToolsOnAir: Modern Broadcast Workflows on Backblaze
Presenter: Peter Steiner, Chief Business Officer, ToolsOnAir
Peter Steiner’s session, “Record, Store, Play: Modern Broadcast Workflows on Backblaze,” brings ToolsOnAir’s deep broadcast expertise to bear on what it looks like to build a complete ingest-to-playout workflow with Backblaze B2 as the storage foundation.
ToolsOnAir has been building Apple-based broadcast solutions for over a decade, with deployments across broadcast, ingest, and storage workflows worldwide. This session is for anyone running live or near-live operations who wants to understand what a modern, cloud-native broadcast stack actually looks like in practice.
The final session tackles a problem that’s only growing: As video libraries scale into the billions of assets, compliance workflows built for smaller operations don’t hold.
Ethan Steininger’s session, “What You Miss Can Cost You: AI-Powered Media Compliance at Scale on Mixpeek and Backblaze B2,” shows how Mixpeek’s multimodal AI infrastructure platform transforms unstructured content—video, images, audio, and documents—into searchable, programmable assets through a unified API.
Before founding Mixpeek, Ethan led search at MongoDB, and today Mixpeek powers enterprise workflows across media, adtech, healthcare, and brand safety, with core technology spanning feature extraction, multimodal retrieval, and a custom-built distributed vector store engineered for billion-scale workloads.
The Bigger Picture
Ten companies, one through-line: storage that integrates cleanly across the entire media stack changes what’s possible. As I put it in my article for Post Perspective:
What we are seeing is a broader realization that infrastructure decisions directly shape how teams build and operate. When pricing models penalize access or iteration, teams naturally limit how often they experiment or how much data they retain. That has a direct impact on product velocity and long-term value creation.
Backblaze didn’t have to react to this shift; it’s how we have always approached the market. Our cost model removes barriers like egress and transaction fees so teams can operate freely. That allows media organizations to focus on where value is actually created—whether that is content, audience engagement, or new AI-driven capabilities—while still maintaining craft excellence.
When your foundation is cost-efficient, S3-compatible, and built for reliability at scale, every tool in the ecosystem above it gets to do its best work. That’s what we mean when we talk about “building the future of media workflows”—not just that Backblaze stores your files, but that it enables the ecosystem built on top of it.
Join Us at NAB Show 2026
We’d love to show you around. Whether you want to catch one of the in-booth presentations, sit down for a workflow consultation, or talk through your specific storage and integration challenges, our team will be on-site all week.
OpenClaw crossed 250,000 GitHub stars in 60 days, surpassing React’s decade-long record to become the most-starred software project on GitHub. At GTC 2026, NVIDIA CEO Jensen Huang declared it “the operating system for personal AI” and told the room: “For the CEOs, the question is, what’s your OpenClaw strategy?”
At NVIDIA’s Hack for Impact hackathon at GTC, I built and watched engineers build autonomous agents on NemoClaw, OpenClaw, and Nemotron. Wildfire detection ingesting NASA satellite data. Crime pattern analysis across police jurisdictions. Energy grid anomaly forecasting.
The same architectural question surfaced in every project: agents that collect and generate data at scale need a deliberate strategy for archiving, retaining, and surfacing that data. Without one, agent-produced artifacts become dark data, generated but inaccessible, unversioned, and invisible to the rest of the organization. That question only gets more consequential in production.
Beyond NemoClaw’s runtime governance: Architecting for data persistence
NVIDIA’s NemoClaw wraps OpenClaw with security through OpenShell, a runtime that sandboxes each agent at the kernel level. Network requests, file access, and inference calls are governed by declarative YAML policy, enforced outside the agent’s process so the agent itself can never override them.
OpenClaw agents create workspace files (SOUL.md, USER.md, IDENTITY.md) that define the agent’s personality, preferences, and behavioral context. Inside a NemoClaw sandbox, this state lives in a Kubernetes Persistent Volume Claim inside an embedded K3s cluster, and the community is already asking for better backup and restore workflows on the NemoClaw GitHub repo.
At fleet scale, with dozens of agents each maintaining persistent memory, conversation history, and skill artifacts, a durable storage layer beneath the runtime is what keeps agent state from becoming disposable. What that layer looks like depends on the type of data your agents produce.
The agentic data layer
Two categories of data define the storage requirements for autonomous agents.
Operational artifacts
Autonomous agents generate reports, analyses, transformed datasets, alerts, and increasingly, multimodal outputs like processed video, audio, and images. Inside NemoClaw’s sandbox, filesystem access is confined to /sandbox and /tmp, both ephemeral by design.
Cloud storage decouples the artifact from the runtime, enables scoped access via URLs, and plugs into every major orchestration framework. Bucket-level permissions and scoped application keys extend governance into the storage layer, so each agent or agent class gets write access only to its designated output path.
Lineage matters here too: Each artifact should trace back to which agent, model, inputs, and policy produced it. Our GTC project, FireWatch, used Backblaze B2 exactly this way, uploading wildfire risk reports with a bucket-scoped key, generating shareable URLs, and embedding them directly in stakeholder alert emails.
State and compliance data
Agent memory, skill artifacts, and audit logs from policy decisions all require durable, long-term retention. NemoClaw’s privacy router splits inference between local and cloud models based on policy, generating routing metadata that compliance teams will want to retain and query. Cloud storage brings high durability, append-only immutability for audit trails, and lifecycle policies for tiered retention as data ages.
We built an open source OpenClaw plugin (openclaw-b2-backup) around this: Encrypted snapshots of agent config, memory, and sessions pushed to B2 on a daily cron, before compaction events, and on gateway shutdown. Three fields to configure, rollback from chat, one-command migration to a new machine.
The agent landscape is expanding. The storage pattern is consistent.
The open-source, autonomous AI agent ecosystem now spans at least 16 variants, each optimized for a different deployment context: NanoClaw for container-isolated security, ZeroClaw for edge deployment in a 3.4MB Rust binary, IronClaw for regulated industries through Trusted Execution Environments, managed platforms like ClawCloud and Maxclaw, and Qwen-Agent from Alibaba for the Chinese developer ecosystem.
Whether self-hosted or managed, all of them produce artifacts that need to persist beyond the runtime. Teams building autonomous agents for their organizations will need durable output sharing, state backup, and cross-agent data access regardless of which runtime they choose.
What enterprise AI leaders should build toward
Architect your agent data orchestration on cloud storage. As organizations scale from initial agent deployments to multi-team production workloads, data volume grows with every agent added, every week they run, and every modality they process. Agents gather, generate, and transform data continuously. Cloud storage gives you a durable layer for managing that lifecycle: ingestion and collection, versioned outputs, long-term archival, lifecycle policies for retention, and portability across agent platforms as your organization’s runtime choices evolve. Establishing this now, while the ecosystem is still forming, is the strategic move.
Automate agent state backup as part of your deployment standard. Agents building context across customer data, internal systems, and team workflows for weeks carry real operational value. Automated workspace snapshots protect that investment, create a disaster recovery path, and enable migration across environments.
Design for lineage and audit from day one. Policy decisions, tool invocations, inference routing, and multimodal processing chains all generate metadata. For enterprises operating under SOC 2, HIPAA, or GDPR, storing lineage and audit data alongside your artifacts in cloud storage means your compliance posture is ready before the audit, not after.
NemoClaw brought governance to the agentic stack. If your organization is deploying autonomous agents today, data orchestration and lineage are your next architectural decisions. Get them right early, and your agents scale with durable state, shareable outputs, and auditable history from day one.
Cloud performance is easy to claim and hard to measure. As data volumes grow and workloads become more complex, the real question isn’t just how fast a provider is—it’s how that performance holds up in practice, and what you’re actually getting for what you pay.
Our answer to that challenge is Performance Stats, the most recent addition to our Stats franchises, Drive Stats and Network Stats. This ongoing, quarterly report will share performance testing results for both Backblaze and competitors, as well as the testing methodology so that anyone can recreate, compare results, and contribute to building better tests if necessary. (And, as always, we love the healthy debate in the comments section and beyond.)
By sharing the full results—strengths, limitations, anomalies, and more—we’re working to give developers and teams a more complete picture of how cloud storage providers perform in practice. We’re building a dataset over time, and we’re just at the beginning—let’s dive in.
And we can talk about it, too
Join the Performance Stats team on Thursday, April 9, 2026 to go over the stats, talk about testing methodology, and more. Have a question for us? Submit your question ahead of time here.
Q1 2026: The results
We ran performance testing for Backblaze B2, AWS S3, Cloudflare R2, and Wasabi Object Storage in two regions, US-East and the EU-Central. Our EU data center is in Amsterdam, and just like in our first round of testing, we matched the other cloud provider locations as closely as possible. You can jump to the testing methodology if you’d like more details.
Key findings:
Average upload and download times for US-East improved across nearly all providers and file sizes compared to Q4 2025. Backblaze led in upload averages for 256KiB and 5MiB files, with Wasabi taking the 2MiB category.
Sustained throughput testing continues to tell a different story than averages alone. As with last quarter, the spread between highest and lowest values per file size remains wide—particularly in multi-threaded tests, where providers’ architectural choices show up most clearly.
EU-Central results show meaningful regional variation. Provider rankings shifted between US-East and EU-Central—for example, Cloudflare R2 performed notably well on EU upload and download averages, while Wasabi led in several EU upload throughput categories. The takeaway: geography matters, and no single provider’s US performance predicts their EU performance.
Multi-threaded download tends to see a sharp rate of increase and then level out. In both US-East and the EU and for most of the tested providers, we see a sharp increase in mebibytes per second performance from the 256KiB to 5MiB file size, then a relatively flat trendline thereafter. This is an early trend that has existed quarter-on-quarter, and worth watching over time.
And, here’s a roadmap if you want to quickly reach each test:
We want to cut through the noise on cloud performance, and we’re working to build a transparent dataset to support that. This transparency is also why we’re publishing our testing methodology.
We want to take a hard look at performance on a level playing field for two reasons:
Buyers should know what they’re getting and have the tools to sniff out the hype and misleading messaging many providers peddle about their performance.
If we don’t measure ourselves, we won’t get better. We want you to understand where we’re doing well today, and we want to take you along for the ride as we work to improve where we’re not.
We’ve outlined the methodology at the end of this report. And, across the board, it’s important to note that this project is still young. Young datasets have lots of variability before they show true patterns: So, the best way to understand these results is to re-create them yourselves within your own tech stack.
On the subject of transparency, let’s talk rate limits
From the start, we expected the data to surface both strengths and weaknesses, which is why transparency has to include context—not just raw results. This time around, the thing that was revealed is our rate limits.
At a certain level of scale, cloud storage providers have to implement rate limits to ensure consistent performance and keep the platform secure from intentional or unintentional volumetric attacks. And, we even saw an example of that behavior last quarter in the Wasabi data—in that case, the limit they have in place is that they don’t allow users to run HTTP requests for the first 30 days of a new account period.
Our rate limits work differently. I’m simplifying a bit, but there are three different ways you can trigger a rate limit: too much bandwidth being pushed, too many requests per second, or too many threads running concurrently. On the user’s side, you see either a 429 error (if you’re running our B2 Native API) or a 503 error (if you’re running the S3 compatible API).
We didn’t hit rate limits in all tests. In fact, we only hit them in the multi-threaded throughput tests at the larger file sizes, which indicated to us that we were running into bandwidth caps. And, since throughput testing by nature is a stress test, this is relatively unsurprising. We’re trying to push as much data as possible in a five minute period—if the platform doesn’t know testing is happening, it can look like a volumetric attack.
Now to the sticky part from a reporting perspective: When we set out to write this report, the testing methodology includes the parameter that we’d test standard account tiers. In practice, we actually have no control over whether our testing accounts are being treated differently on the back-end with other providers, for better (preferential treatment) or worse (throttling). That’s also why we run testing from an independent Vultr server—it means we aren’t using a Backblaze-owned IP address, so the testing account isn’t identifiable by other providers. The accounts are being judged on their behavior.
So what do we do here? How do we balance testing against real world behavior? We decided to show you what it looks like when you hit rate limits and outline some potential steps for user-side mitigation.
On every cloud storage platform, we can expect that there are default rate limits applied. When we saw our own, we had the advantage of knowing that that’s what we were seeing—if we were in the real world, we’d do additional investigation to confirm. From a testing perspective, we went forward in a way that would be the most likely scenario in the real world: We incorporated an auto-retry script.
In all cases for this report, we were hitting bandwidth caps at the larger file sizes in the multi-threaded throughput tests. So, if the test tried and failed, we raised that limit and only that limit—all other account parameters stayed in line with the default standard account. In the real world, you would have completed your investigation, then reached out to Support to raise bandwidth caps, which would then apply to your account going forward.
There are actions you can take before requesting a change, especially because sometimes API calls are failing for other reasons. So it’s helpful to do things like retry with exponential backoff, double check your lifecycle rules and other automated processes (especially sequential operations), increase or decrease thread count, change file size, etc., and keep all the logs, too. Sometimes just those things will solve the issues you need to solve.
More importantly, all of those actions are things that will give you more information about what type of configuration issues you’re having, and, if you are running into a rate limit issue, (at least with us) you can request a specific configuration change. For example, in this case, we only raised the bandwidth cap, and kept all the other account configuration variables in line with our standard tier. Our concern was to keep the testing as fair and consistent as possible. But, in a real-world scenario, that may mean you’d avoid something like jumping into a different pricing tier. In all cases and with all providers, testing and communication are key at this stage. Data, as always, is king.
Back to this report: we have two important impacts. First, we can’t confidently make quarter over quarter comparisons this time around because we’ve changed the testing methodology (though we can do so in our upload and download averages, as they weren’t affected). We may point out observational patterns, but we can’t say they’re significant. And hey, the dataset is young—we shouldn’t be doing that yet anyway. Second, if we hit a rate limit, we went ahead and included that data as a separate line item in our tables—so I’ve updated our testing methodology accordingly.
With that out of the way, let’s get into the report.
US-East
This quarter, we’ve added a second region to our reporting. We’ll start with US-East, then move to EU-Central.
Upload comparisons
This test shows the average time in milliseconds it takes to upload a file. Averages were taken across a month of data and for three different file sizes.
In these tests, a lower result is better, and as with the last report, we’ve highlighted the category winners in green for readability.
We’ve got a young dataset here, so it’s hard to attribute significance this early, but let’s look at a quarter-over-quarter comparison. (Note: We did not have data from Wasabi last quarter.)
Interestingly, every provider had lower average upload times. Once again, Backblaze wins for 256KiB files. Last quarter, AWS led in the other two file sizes, but this quarter, Wasabi took over in the 2MiB category and Backblaze in the 5MiB.
Five minute multi-threaded upload benchmark
In these tests, a higher result is better, as the result represents more average data being pushed in the five minute time period. This gives us quite a bit more information than just average upload time for a single file—it tells us the sustained amount of data you can push to a cloud storage provider in five minutes. This is also where we see our first rate limit in action.
You’ll notice that the first two values for the rate limited and un-rate limited account are the same—which makes sense, because they hadn’t triggered the bandwidth cap. In the rate-limited version, the values in the higher file sizes are suspiciously similar. We had the benefit of knowing we were hitting our own rate limits, but if you were doing external testing, you’d go through the things we talked about above. Different providers have different policies on what they can and can’t allow, so check out each platform’s documentation for clarity.
As for the rest of the data: Wasabi sweeps this category. As our dataset grows over time, we’ll have more of an ability to say what’s “normal.” And, as always, your use case comes into play here—there’s a difference between baseline averages and what you can tolerate within your workflows, and when you’re making business decisions, the latter is where you find real value. Trade-offs are strategy.
While we can’t perfectly compare quarter-on-quarter because of the methodology change, it’s interesting to note that we still have a wide variance between our highest and our lowest values per file size category in this test type, which is in line with what we saw last quarter. If that pattern continues in future quarterly datasets, we should make sure we take it into account when interpreting outliers.
Now let’s bring forward our alternative visualizations with the rate of increase:
And check in on clustering within the file sizes:
Five minute single threaded upload test
Once again, higher is better in this result, and it measures the sustained amount of data you can push to a server in a single thread with different file sizes.
Multi-threaded tests reveal what happens when you parallelize workload or data transfer whereas a single-threaded test measures how efficiently a provider handles one request. So, from our perspective, single threaded operations show us how a provider handles overhead including connection setup (handshake), request routing, waiting for the first byte, and then actual data transfer. It matters when APIs are making sequential calls or you have latency-sensitive or small-object workloads.
In this test, Backblaze leads in the 256KiB, 50MiB, and 100MiB categories, and AWS leads in the 5MiB category. Here’s our line graph:
And, like the multithreading results, we see a high degree of variance between our highest and lowest results, which becomes even more apparent in our clustered view:
Download comparisons and TTFB
As with our upload average data, lower is better. This test measures how long it takes a single file to download, on average.
Last quarter, AWS led in all file sizes. This quarter, Backblaze overtakes in the 2MiB category, while Amazon S3 still leads in time to first byte (TTFB) as well as the 256KiB and 5MiB file sizes. Let’s zoom in on time to first byte (TTFB).
And take a look at our QoQ comparison:
Again, our dataset is too young to determine the significance of changes within each category. Observationally, it’s interesting to note that most of these numbers improved.
Five minute multi-threaded download benchmark
In these tests, a higher result is better, as the result represents more average data being downloaded in the five minute time period. And, as above, we can see Backblaze rate limits in the data.
Backblaze leads for 256KiB files, AWS for 5MiB and 50MiB files, and Cloudflare for 100MiB files.
Let’s give ourselves the same charts as our upload tests. Here’s the trendline:
This chart makes clear how comparatively well Cloudflare R2 does at the larger file sizes—and as their core business is CDN, that makes a lot of strategic sense.
Here’s the per-file size clustering:
Five minute single-threaded download throughput
Wasabi comes in first for 256KiB and 5MiB files, and Backblaze for 50MiB and 100MiB files.
And here’s our clustering:
EU-Central
Welcome to the new region! We’ll keep editorializing to a minimum—here’s the EU data.
Upload averages
In this test, Cloudflare R2 takes the 256KiB category, while Backblaze is the fastest for both 2MiB and 5MiB file sizes. It’s tempting to compare these numbers to the US-East performance, but certainly premature.
At the very least, it’s a good reminder of the strength of a multi-cloud approach—there’s always a balance between relying on a single provider regardless of their geographic presence or their strength in your particular use case needs. Specialists bring value to the table if and when their addition doesn’t outweigh the operational costs of complexity.
Five minute multi-threaded upload test
Top of section reminder: Higher is better in this test.
In these results, Wasabi leads in the 256KiB and 100MiB categories, while AWS wins out for the 5MiB and 50MiB file sizes.
Here’s the trendline:
And here’s the by-file-size clustering:
Five minute single-threaded upload test
Wasabi dominates this category. Backblaze is a close second for the smallest file size, and S3 takes second for both the 50MiB and 100MiB categories.
Download averages and TTFB
Cloudflare performs well in this region, with the fastest average times in TTFB, 256KiB, and 2MiB categories. AWS wins on the remaining 5MiB file size. Here again we see a huge delta between the highest and lowest average times.
And, here’s our TTFB chart:
Just like in the Drive Stats series, when we see numbers like this, we do some internal investigation—comparative numbers show us where we can improve, which is why this testing is so critical. We’ve identified an issue we believe was contributing; we’ll report on the impact of our fixes in a future report.
Five minute multi-threaded download test
Backblaze leads in the 256KiB file size, while AWS leads in the other three categories. Let’s look at our alternate views.
Five minute single-threaded download test
Wasabi comes first in the 256KiB file size, while AWS leads in all other categories. Here’s the trendline:
And our clustering:
Test methodology
Our goal with these benchmarks is simple: to understand how our cloud performs under real-world conditions and to share that information as clearly as possible. To do that, our Cloud Operations team runs repeatable, synthetic tests that measure upload (PUT) and download (GET) performance.
We ran both upload and download tests across all six vendors. Upload tests measured average total time to download a single file of the following file sizes:
256KiB
2MiB
5MiB
Download tests measured:
Time-to-first-byte (TTFB)
Average total time to download the following file sizes:
256KiB
2MiB
5MiB
Throughput tests run in five-minute profiles to observe consistency over time, and we ran both single and multi-threaded upload and download tests. From a practical perspective, what’s happening in this test is that we’re pushing repeated requests to a cloud storage provider as many times as we can for five minutes. In multi-threaded tests, we run 20 concurrent threads. Throughput tests use the following file sizes:
256KiB
5MiB
50MiB
100MiB
All tests originate from a Vultr-hosted Ubuntu virtual machine (VM) located in the respective test regions (US-East and EU-Central), routing through Catchpoint’s network into the object storage regions. By keeping the source environment stable and the test target consistent, we isolate performance variables within each provider’s infrastructure rather than the test environment itself.
Consistency measures
To ensure each test result represents genuine performance rather than environmental noise, we built repeatability into the process:
Identical test instances: All runs used the same VM type, operating system (OS) image, and configuration.
Fixed regions: Tests originated from the same location (NY/NJ) targeting the same US-East or EU-Central region across providers.
Controlled routing: Network paths were held constant through Catchpoint’s monitoring network to minimize geographic or peering variation.
Repeated runs: Each test profile (5 min) was executed multiple times, and averages were used to reduce the impact of transient spikes.
Standardized payloads: All uploads and downloads used identical objects to ensure a consistent file-size baseline.
Unchanged test intervals: Tests were scheduled at regular intervals over multiple days to capture both typical and outlier performance.
About synthetic testing
Synthetic monitoring provides a controlled, apples-to-apples comparison, but it doesn’t replicate every production workload. These tests are run outside our own infrastructure—from neutral vantage points—to simulate a customer’s experience at the “last mile.” This distinguishes our approach from competitors who benchmark internally under optimized conditions.
It’s important to note that synthetic results won’t mirror every customer’s experience. Different architectures, connection paths, and file patterns will produce different performance profiles. Our intent is to offer transparency into the methodology and relative behaviors, not to suggest that all workloads will perform identically.
Limitations and future work
Every benchmark is an approximation. These results provide a controlled look at how cloud storage performs under repeatable conditions, but they don’t capture every variable in production environments. Below, we outline what our current tests don’t measure and where we’re headed next to deepen the picture.
Synthetic, not real-world workloads: These benchmarks simulate real activity but don’t reproduce the full variability of customer workloads, concurrency levels, or data locality patterns. They are best understood as directional insights rather than absolute truths.
The internet is the internet: Once traffic leaves the test node, we can’t control the routing, peering, or transient network conditions between endpoints. Each provider’s own network policies and routing optimizations—for example, Wasabi’s inbound connection rules—can influence the results.
File size constraints: Our testing environment currently limits file sizes to 10MiB or smaller due to timeout thresholds. That means we can’t yet model the large-object transfers typical of certain workloads.
Static test conditions: All tests were conducted from a single region (NY/NJ to US-East cloud providers). Real-world customers operate globally, where peering arrangements, congestion, and latency differ widely.
Potential caching effects: Although we designed the tests to avoid cached reads, Catchpoint does not allow full data randomization. It’s possible some repeated reads benefited from intermediate caching at any network layer.
Traffic shaping and rate limiting: Providers may apply rate limits or throttling when detecting high-frequency test traffic. For example, Wasabi temporarily blacklisted our IPs due to testing volume—a reminder that these results represent observed behavior, not formal service guarantees.
Your mileage may vary, or what this means in the real world
One of the reasons it’s so hard to get directly comparable performance benchmarks is because there are so many configurable elements on the user’s side that can affect the results. For example, if you know that your provider is faster on smaller files, you might choose to store your unstructured data in smaller parts so that you achieve faster performance.
We did some comparison between existing use cases that Backblaze succeeds based on the data above including AI/ML inference, feature stores and embedding lookups, LLM-based RAG systems, log and event analytics, interactive data lake querying, and CDN origin. The biggest takeaway is something that we noted when talking about the EU metrics—specialists bring flexibility to the table, which is where you truly start to unlock value.
For a cloud storage provider, tracking these metrics over time and comparing to other aspects of our internal architecture enables us to support ongoing and continual performance improvement, and to understand how much of an impact single changes might make. This means that what seems like a simple project to change the way we read header requests can produce asymmetrically favorable results.
What’s next?
Performance is an evolving target, and this dataset is still early. What we can say today is directional: different providers behave differently under different conditions, and those differences become more pronounced as workloads scale.
We’ll keep expanding this work in future reports—across regions, workloads, and test conditions—with the expectation that clearer patterns will emerge. In the meantime, the most valuable use of this data is to map it against your own systems, your own constraints, and your own definition of performance.
Modern infrastructure teams increasingly interact with their systems through automation and AI-assisted tooling. Terminal-native agents like Claude Code are beginning to act less like chatbots and more like operational collaborators, able to inspect environments, run commands, and help maintain infrastructure.
Today we’re releasing a new open-source tool designed for that workflow: the Backblaze B2 Cloud Storage Skill for Claude.
This GitHub repository provides a structured skill that allows Claude-based agents to safely interact with Backblaze B2 Cloud Storage through the B2 CLI. Instead of manually running storage audits, searching buckets, or reviewing lifecycle rules, you can ask an AI assistant to help perform those tasks directly in your development environment.
The result is simple and powerful: An open source natural language interface for inspecting and managing B2 Cloud Storage, built with guardrails.
What is the B2 Cloud Storage Skill for Claude?
The B2 Cloud Storage Skill for Claude is an open-source repository that enables AI-assisted management of B2 buckets using the official Backblaze B2 CLI.
The project includes three primary components:
1. A Claude Skill Definition
The skill file provides structured instructions that teach Claude how to safely interact with B2 Cloud Storage. It defines the commands the assistant can use, outlines safe operational practices, and establishes restrictions around sensitive data and destructive actions.
This allows Claude to perform storage operations while respecting operational safeguards.
2. A Storage Audit Script
The repository includes a Python script that analyzes the contents of a bucket and produces a structured report. The audit can:
Summarize storage usage by directory prefix
Analyze file types and extensions
Identify files older than 90 days
Flag objects larger than 100MB
Detect potential duplicates based on filename
The result is a quick operational snapshot of a bucket’s structure and usage patterns—useful for cost awareness, lifecycle planning, and housekeeping.
The skill supports per-project configuration through a .claude/b2-config.json file. This allows developers to specify a default bucket, a working prefix, or a project-specific credential file.
In practice, that means different repositories or services can point to different storage buckets without changing global CLI configuration.
How to use it
The skill is designed to work in environments where Claude Code or similar agent-based developer tools can execute terminal commands.
A typical workflow looks like this:
Install and configure the B2 CLI.
Authorize the CLI with a B2 application key.
Add the skill repository to your Claude environment.
Optionally configure a project-specific bucket.
Once configured, you can ask Claude to perform storage tasks directly from your terminal.
Examples include:
Audit the contents of this bucket.
List files older than 90 days.
Show the largest objects in this prefix.
Check the bucket’s lifecycle rules.
Find duplicate filenames across directories.
Under the hood, the assistant is running standard B2 CLI commands and the included audit script. The skill simply provides the structure that allows an AI agent to use those tools correctly.
This approach keeps the operational layer transparent: Everything ultimately resolves to normal CLI commands you can run (and double check) yourself.
Why it matters
Cloud storage environments grow quietly.
Buckets accumulate logs, backups, generated assets, and intermediate files over time. Without periodic inspection, those collections can become difficult to understand or maintain.
Historically, storage audits have been manual exercises: writing scripts, exporting listings, or running ad-hoc commands.
AI-assisted tooling changes that interaction model.
Instead of constructing queries, operators can ask for insights:
Where is the storage concentrated?
Which files are stale?
Are lifecycle policies doing their job?
Are there large objects that should be archived or removed?
The B2 Cloud Storage Skill bridges the gap between AI-assisted workflows and real storage infrastructure.
Just as importantly, the repository is designed with safety in mind. The skill restricts commands that could expose credentials, requires dry-runs before deletion operations, and warns when actions could change bucket visibility.
In other words, it treats AI as an operational assistant—not an autonomous administrator.
Open source and extensible
The repository is intentionally lightweight and open.
It’s meant to serve as both a practical tool and a starting point for developers exploring how AI agents can interact with storage infrastructure.
Possible extensions include:
Automated lifecycle policy recommendations
Deeper storage analytics
Integration with monitoring pipelines
Custom audit rules for specific workloads
If you’re experimenting with AI-assisted operations—or simply want a faster way to inspect your B2 Cloud Storage—this skill provides a practical place to start.
You can explore the repository and try it yourself here:
As demand for AI infrastructure keeps climbing, a new wave of providers is proving there’s real appetite for something other than the traditional hyperscaler model. They’re moving fast, specializing deeply, and building strong businesses around the layers that matter most to their customers: GPU access, high-performance compute, AI services, and developer experience.
That momentum is real, as is the next bottleneck. For many neoclouds, the challenge is no longer just how to deliver more compute. It’s how to deliver a more complete platform without taking on all the complexity of becoming a full-stack cloud provider. And that usually brings teams to the same question: Sshould we build our own storage layer?
Key points: Why should neoclouds care about specialized storage?
Neoclouds are capturing a major market opportunity by specializing in compute, AI, and high-performance infrastructure instead of trying to replicate the hyperscaler model. But without an independent, S3 compatible storage layer, many providers run into a split-stack problem: compute lives on the neocloud while data stays in a major cloud, bringing egress fees, friction, and architectural sprawl.
Teams that decide to build storage themselves often underestimate what that really means. Whether the path is open-source software like Ceph or purpose-built hardware, the result is often the same: Slower execution, more operational burden, and less focus on the product that actually differentiates the business.
The stronger strategy is to treat storage as a specialized tech stack layer and intentionally partner to solve the need, so internal teams can stay focused on compute, AI services, and customer experience.
Backblaze gives neoclouds an S3 compatible object storage backbone that can be integrated quickly, scaled immediately, and delivered without the overhead of building and operating storage from scratch.
The real neocloud opportunity is specialization
The shift toward neoclouds is really a shift toward specialization.
For years, the default assumption in cloud infrastructure was that the winning model looked like a hyperscaler: Build the entire stack, own every layer, and expand horizontally into as many services as possible. That model produced scale, but it also produced operational sprawl, complexity, and costs that many customers are increasingly motivated to avoid.
Neoclouds are succeeding because they’re taking the opposite path. Instead of trying to be everything to everyone, they’re building best-of-breed platforms around targeted workloads and high-value services. That’s especially true in AI, where performance, cost control, and speed matter more than a long menu of loosely related products.
But the closer a neocloud gets to becoming a full platform, the more pressure it faces to solve for storage.
The split-stack problem gets expensive
Without integrated object storage, customers often end up in a split-stack architecture. They run compute on a neocloud, but keep their data parked in a major cloud provider, which creates problems quickly.
For example: Large training datasets, model checkpoints, and output artifacts have to move across environments, costs become harder to predict, egress charges start to shape architecture decisions, and performance can suffer when storage and compute are no longer designed to work together.
At that point, storage becomes a core requirement for offering a platform that feels complete, efficient, and economically viable.
So teams ask the obvious question: should we build it ourselves?
Building storage usually means building a second company inside your company
This is where the conversation often gets framed too narrowly.
On paper, the decision can look straightforward: deploy open-source software such as Ceph, or design purpose-built hardware for tighter control over performance and economics.
In reality, both paths create the same strategic problem. They pull engineering focus away from your core platform and into a long-term storage business you never actually meant to start.
That matters because storage is not just infrastructure. It is an operating discipline. It comes with its own tuning, scaling, durability trade-offs, support burden, procurement risk, migration complexity, and day-two operational entropy.
Once you build it, you own all of it.
The software trap: Ceph is open source, not low overhead
Ceph is often the default option for teams exploring S3 compatible storage because it appears flexible, proven, and relatively accessible on commodity hardware.
And to be clear, Ceph can be powerful. But there’s a big difference between deploying Ceph and running it well at scale.
In production, Ceph demands specialized expertise. Teams have to manage CRUSH maps, OSD tuning, replication behavior, rebalancing events, and the network impact that comes with those changes. Those are not occasional tasks. They are part of the ongoing operational load.
That burden grows as environments get larger and more performance-sensitive.
For AI and high-performance compute use cases, generic Ceph deployments can also become throughput bottlenecks. When storage ceilings start constraining training jobs or data-intensive workflows, the problem is no longer confined to the storage team. It starts affecting the value of your core compute offering.
And migration is rarely simple. Because data is distributed across the cluster in ways that are optimized for internal resilience, moving out of a Ceph environment can become a resource-heavy extraction exercise that introduces risk to live workloads.
So while Ceph may reduce license costs up front, it can create a much more expensive operational reality over time.
The hardware trap: more control, more rigidity
For some neocloud teams, custom storage hardware feels like the more strategic answer.
The logic is easy to understand: if storage is critical, why not optimize the hardware and software stack together and get more predictable performance?
The issue is that custom storage hardware rarely stays clean and predictable for long.
Supply chains change. Drive capacities shift. Components become harder to source consistently. Architectures designed around one hardware profile suddenly have to absorb another. This dynamic can leave teams paying for density they can’t fully use or reworking systems to accommodate equipment that wasn’t part of the original plan.
Durability management adds another layer of complexity. As systems age, parity strategies and erasure coding decisions may need to change to maintain reliability. That can reduce usable capacity, increase cost per terabyte, and trigger compute-intensive re-encoding processes at exactly the wrong time.
Then there’s the networking layer. At scale, object storage is not just disks and nodes. It also depends on a traffic management architecture capable of handling massive ingress and egress flows without introducing opaque failure points. Whether you build around open source components or buy expensive hardware appliances, you’re signing up for another category of highly specialized infrastructure work.
And all of that comes with a capital model that is harder to unwind. Hardware investments lock teams into depreciation cycles and planning assumptions that may not match where the market is headed next.
The strategic shift: own differentiation, not every layer
The most important shift here is not technical. It’s organizational.
At a certain point, the storage question becomes a question of where your best people should spend their time.
Should your engineers be tuning replication policies, planning hardware refreshes, and troubleshooting storage network behavior?
Or should they be improving the platform features your customers actually choose you for?
For most neoclouds, the answer is clear.
Their advantage comes from how well they deliver compute, how quickly they adapt to AI demand, how smooth their developer experience feels, and how effectively they help customers run modern workloads. That is where focus compounds. That is where differentiation lives.
Storage matters enormously, but that does not mean it has to be built in-house.
Storage works better as a specialized utility
The neocloud ecosystem works best when providers can connect to open, specialized layers instead of rebuilding the entire stack themselves.
When storage is treated as a utility rather than an internal R&D project, teams can move faster and stay aligned with what the business actually needs. They avoid procurement cycles, reduce operational overhead, and eliminate a category of complexity that would otherwise keep expanding over time.
Equally importantly, they can offer customers a more complete and coherent platform without forcing data to remain trapped in legacy cloud environments.
How Backblaze helps neoclouds move faster
Backblaze gives neoclouds an independent, S3-compatible object storage backbone that can plug into existing compute, AI, and container workflows without requiring a storage buildout from scratch.
That means teams can:
Integrate with existing tooling: Use a drop-in, API-compatible storage layer that works with existing workflows, SDKs, CLIs, and infrastructure tools.
Reduce operational burden: Offload the complexity of durability engineering, bit-rot protection, fleet management, and storage operations.
Avoid punitive egress economics: In Backblaze-powered and colocated partner environments, move data between compute and storage without the cost friction that often comes with major cloud architectures.
Scale immediately: Go from terabytes to exabytes without waiting on hardware procurement, deployment schedules, or expansion projects.
Keep teams focused: Direct engineering effort toward the product roadmap instead of a second internal storage program.
Backblaze also brings the underlying scale and performance neoclouds need to support modern AI and data-intensive workloads, including up to 1Tbps aggregate throughput, 11 nines of annual durability, a 99.9% uptime SLA, and enterprise security and compliance capabilities.
Build what matters
Neoclouds are winning because they know where to specialize.
That focus is their strength. It is also their opportunity.
The fastest path to a stronger platform is not to recreate every layer of the cloud stack. It is to build the parts that make your business distinct, then connect them to the right partners for the rest.
Storage is too important to ignore, but it is also too easy to underestimate.
If you want to move faster, serve customers better, and keep your roadmap centered on what makes your platform valuable, don’t turn storage into a distraction.
Build what matters. Let Backblaze handle the storage.Interested in learning how Backblaze supports neocloud platforms? Explore B2 Neo or talk with our team about building a more open, AI-ready storage architecture.
Lots of us were taught that pi equals 3.14. Maybe 3.14159 if your teacher was ambitious. Akira Haraguchi, who holds the Guiness Book of World Records title for reciting the most digits of pi in a single run, got up to 100,000 digits in 16 hours.
That’s still only a fraction of the record digits of pi that are calculated—3.18471338 × 10-8% to be exact. So why do we need that much pi?
A pi record isn’t a burst workload. It’s a system that runs at sustained pressure for months, writing checkpoints, flushing buffers, and proving that nothing quietly breaks. Last December, StorageReview set a new record, calculating 314 trillion digits on a Dell PowerEdge R7725.
Pi has long served as a proving ground for computational systems because it offers a deterministic workload with clear correctness criteria and sustained compute and input/output (I/O) demands. Records in pi computation trace back decades and reflect both mathematical and computational advances. In 1949, ENIAC—the first programmable, electronic, general-purpose, digital computer—computed 2,037 digits of pi in about 70 hours, an early demonstration of electronic computing capability that was eventually published in the paper, “The ENIAC’S 1949 Determination of π.”
Algorithms have evolved significantly since then. The Chudnovsky algorithm, developed in 1988, is one of the fastest converging methods for high-precision pi calculation and has been used in many modern record attempts because of its efficiency at large digit counts.
Pi calculations do not mirror typical enterprise workloads such as databases or machine learning training, but their determinism and large scale make them useful for evaluating sustained performance of CPU, memory, and storage subsystems under continuous load. It’s also used in various security functions including random number generation (because computers can’t be truly random), cryptographic algorithms, hash functions, digital signatures, and secure communications protocols like SSL/TLS.
What the 314 trillion digit run represents
In December 2025, StorageReview reported a new record by calculating pi to 314 trillion digits on a single server that ran continuously for approximately 110 days before completion. The achievement emphasizes not only the scale of the computation but also the role of storage architecture, non-uniform memory-access (NUMA) tuning, and system stability in sustaining such a workload.
The raw output of the run, including checkpoints, extended beyond 2PB of data. The finalized dataset hosted in Backblaze B2 exceeds 130TB and is divided into 200GB objects suitable for staged retrieval.
What pi really looks like.
Engineers, researchers, and pi enthusiasts can freely retrieve their own slice of pi (or the whole thing) for analysis, performance characterization, and tool validation. Structuring the dataset into manageable objects enables selective download for analysis, parallelized workflow testing, and evaluation of sustained object retrieval performance.
How to access the dataset
The 314 trillion-digit dataset is available today via Backblaze B2 Cloud Storage.
Submit the required information to receive credentials.
Use the provided instructions to download via rclone, an open-source cloud storage management tool.
The object layout supports both partial and full dataset retrieval strategies.
Enjoy your pi!
With all the ways you can use the pi dataset, we can’t wait to hear what you all are working on. Feel free to let us know what you’re working on in the comments section below, on socials, or by email.
When AWS’s us-east-1 region went down for over 15 hours on October 20, 2025, the cascade of failures exposed just how fragile the internet’s infrastructure has become. Major services like Discord, Slack, Atlassian, and parts of Netflix suddenly went dark. These companies weren’t all direct AWS customers, but the vendors they relied on were. Authentication systems failed. CDNs stopped responding. Monitoring tools went blind. Companies that thought they’d diversified their cloud strategy discovered their backups were just as offline as their primary systems.
The solutions organizations thought they’d implemented, like multi-cloud deployments, redundant architectures, and disaster recovery plans, often provide little more than the illusion of protection.
The illusion of diversification
A company migrates its primary compute workload from AWS to Google Cloud or Azure, checks the “multi-cloud” box, and considers the job done. But authentication still runs through AWS Cognito. The CDN is CloudFront. Monitoring lives in CloudWatch. DNS resolution depends on Route 53. When AWS’s control plane fails, the entire architecture collapses regardless of where the compute actually runs.
ThousandEyes documented exactly this pattern during the October 2025 AWS outage. Packet loss and routing instability affected direct AWS customers and cascaded into dependent networks and services that appeared independent on paper, but shared the same regional infrastructure under the hood. Organizations often discover these dependencies only during outages, when it’s too late to do anything about them.
Why concentration accelerates despite known risks
Everyone knows concentration is dangerous, yet it keeps accelerating. The same forces that make hyperscalers attractive—operational simplicity, unified tooling, procurement efficiency—concentrate risk faster than diversification efforts can mitigate it.
Teams often adopt unified tooling for operational simplicity, which reduces integration costs and builds vendor-specific expertise. As more systems integrate with that tooling, switching costs increase. Eventually, the platform becomes the default rather than a choice. Each new service added to the stack makes it harder to leave.
Hyperscaler architecture isn’t just a risk, it’s a cost
Amplify’s AWS egress fees were growing to 10x their storage costs as customers downloaded more datasets. CTO Ameya Pathare evaluated Azure, Google Cloud, Digital Ocean, and Wasabi before building a modular architecture: Snowflake for data transformation and Backblaze B2 for staging, with outputs available across Google BigQuery and Tableau.
The two-week migration with zero downtime delivered 70% cost savings that compound with every download. When individual providers experience issues, customers maintain access through alternative paths. “If we had stayed on AWS, we’d have needed to change our pricing and pass on those egress fees to the customer,” Pathare says.
Diversification efforts lag behind because they require deliberate architectural decisions that run counter to operational efficiency. According to the CNCF’s 2025 State of Cloud report, 30% of organizations deploy to hybrid cloud environments and 23% to multi-cloud. That sounds encouraging until you look at what they’re actually distributing. Most organizations spread their compute across providers while consolidating authentication, orchestration, and monitoring with a single vendor. Deployment location differs from dependency structure.
Gartner projects that 90% of organizations will adopt hybrid cloud approaches by 2027. But without intentional failure domain separation, these deployments maintain the same concentrated dependencies they’re meant to avoid.
Why untested recovery paths fail
Most organizations treat failover mechanisms like insurance policies: pay the premium, file the documentation, and hope you never need to use it. Then an outage hits and they discover their recovery paths don’t actually work.
Google’s SRE team analyzed this pattern in their twenty-year retrospective: “Recovery mechanisms that are not tested before an incident routinely fail when they are needed most.” Configuration drift makes systems behave differently in production than they did in testing. Teams encounter unfamiliar tooling under pressure. Communication systems fail because they rely on the same infrastructure that’s down.
Three practices separate resilient systems from brittle ones:
Explicit failure domain mapping: Document which components fail together, including indirect dependencies. During Google’s 2017 OAuth incident, teams assumed Hangouts and Meet would remain available for coordination during the recovery. Both services relied on the failing authentication system.
Continuous exercised recovery: Failover paths tested regularly rather than only during incidents. YouTube’s 2016 caching failure required risky load-shedding operations that had never been practiced outside staging environments.
Graceful degradation by design: Systems intentionally reduce functionality rather than collapse completely. Without this capability built in and tested, systems crash entirely instead of slowing down when they encounter partial failures.
Most organizations implement sophisticated monitoring and alerting but lack tested mechanisms to act on that information when infrastructure degrades.
How modular infrastructure reduces risk
Resilient architectures break infrastructure into interoperable components from specialized providers. Organizations can select compute, storage, networking, and delivery independently based on performance and reliability characteristics. A disruption in one layer no longer automatically incapacitates the entire system.
Cloudflare’s October 30, 2023 incident demonstrates what happens when this separation doesn’t exist. A deployment misconfiguration propagated across tightly coupled internal services. Workers KV became unreachable, which cascaded into failures across Pages, Access, Zero Trust, Images, and the Cloudflare Dashboard itself. Shared tooling and control systems collapsed multiple services into a single failure domain, even within a provider marketed as redundant.
Sardius Media demonstrates what modular cloud infrastructure looks like in practice. The company architected its system from inception to be cloud-agnostic, using a race algorithm that queries multiple cloud providers and CDNs for every API call and selects the fastest response. True resilience through competitive redundancy.
The data layer as a gating factor
Storage architecture determines whether all this architectural planning actually works. Can your data move when you need it to? The answer depends on whether systems can replicate and recover across providers under real-world conditions.
Control-plane access matters more than data replication. During Google Cloud’s June 2025 API misconfiguration, Gmail, Spotify, and Cloudflare went dark despite having intact data layers. Replication across availability zones provided no protection when authentication and API access failed.
Three technical barriers trap workloads in place:
Large dataset transfer costs make migration prohibitively expensive.
Proprietary vendor APIs create application lock-in that requires substantial refactoring to escape.
Unpredictable egress charges turn what was supposed to be a temporary deployment into permanent infrastructure because moving the data out costs more than leaving it there.
Storage architectures that support open APIs, predictable pricing, and cross-provider replication enable genuine mobility. Systems can replicate data across providers, recover faster from incidents through parallel data access, and maintain portable compute and delivery layers. Implementation requires mapping both direct dependencies (compute, storage, CDN) and indirect ones (managed services that converge on the same infrastructure), then assigning explicit recovery requirements to critical workloads.
From scattered clouds to a united front
The internet’s reliability challenges stem from correlated dependencies rather than cloud technology. Neocloud ecosystems make resilient architectures achievable by promoting specialization and interoperability.
Organizations can select best-of-breed providers for each infrastructure layer—compute, storage, networking, delivery—without forcing everything through a single vendor’s control plane. Open cloud storage ensures those ecosystems remain flexible under pressure, with data that can replicate across providers, portable applications that aren’t locked into proprietary APIs, and predictable costs that don’t trap workloads in place.
The result is systems that continue operating when individual providers fail. They’ve ensured that failures remain isolated rather than cascading across the entire architecture.
There’s a new open-source plugin that snapshots your OpenClaw config, memory, and sessions to B2. It’s designed to be as simple as possible: Three fields to configure. Rollback from chat. Migrate to a new machine in one restart.
Let’s get into how and why you might want to use it.
OpenClaw keeps everything local. That’s great until it isn’t.
Your config, sessions, memory databases, hooks, cron jobs—everything that makes your OpenClaw instance yours lives on one machine with no built-in redundancy. Compaction can rewrite session transcripts and cause memory loss. A bad config edit or an accidental deletion means rebuilding from scratch: re-onboarding channels, re-pairing devices, re-teaching your agent who you are.
openclaw-b2-backup adds automatic encrypted backups to Backblaze B2 without changing how you use OpenClaw.
Three fields and you’re done
Setup is intentionally minimal:
openclaw plugins install openclaw-b2-backup
Then open ~/.openclaw/openclaw.json and add your B2 credentials to the entry the installer created:
Restart the gateway, and you’re done. Region is auto-detected from your application key. Encryption is on by default. The first backup runs at midnight, and then daily after that. You can change the schedule to weekly or any cron expression you like.
Free tier friendly: Backblaze B2 includes 10GB of free storage. A typical OpenClaw state directory is 50–500 MB, so even with 10 encrypted snapshots retained, you’ll comfortably stay within the free tier.
Backups that actually happen
The hardest part of any backup system is remembering to run it. This plugin takes care of that with multiple automatic triggers:
A daily cron job (configurable) runs a full incremental push at midnight.
Every time you shut down the gateway, a final push runs before exit—so you always have a snapshot of your latest state.
And, before compaction fires (the thing that rewrites your session transcripts and can cause memory loss), the plugin automatically pushes a snapshot. That last one is the one you’ll be most grateful for.
There’s a 5-minute debounce on the compaction trigger, so rapid-fire compactions don’t queue up a dozen pushes.
Rolling back from chat
The plugin registers a b2_rollback tool with your agent, which means you can manage backups conversationally. Just tell your agent:
“Show me my B2 backup snapshots”
And it’ll list all available snapshots with timestamps. To restore one:
“Roll back to the snapshot from before compaction”Before any restore, the plugin automatically creates a safety snapshot of your current state. Safety snapshots are stored separately and never auto-pruned, so you can always recover from a bad rollback. It’s an undo for your undo.
Moving to a new machine
This was one of the most requested use cases: Getting your entire OpenClaw setup onto a new machine without manually copying files and hoping you got everything.
Install the plugin on your new machine, add the same B2 credentials, and restart. The plugin detects the empty state directory, finds your existing snapshots in B2, and automatically restores the latest one. Same memory, same sessions, same config, same personality. No manual file copying.
openclaw plugins install openclaw-b2-backup # Add your B2 config to openclaw.json openclaw gateway restart # Plugin detects empty state + existing snapshots → auto-restores latest
Security by default
Everything is AES-256-GCM encrypted before it leaves your machine. Each file gets a random salt and IV, so identical files produce different ciphertext. The encryption key is derived from your B2 application key via scrypt—no separate key to manage or lose.
Manifests (which contain only file paths and SHA-256 hashes) stay unencrypted so incremental diffing works regardless of encryption. Credentials and auth profiles are excluded from sync by design—secrets stay per-machine, and you re-auth on new machines.
Best practice: Use a B2 application key scoped to a single bucket for least-privilege access. The plugin works perfectly with bucket-scoped keys—region is auto-detected from the authorize response.
Zero external dependencies
The plugin has no external runtime dependencies beyond croner for scheduling. The B2 client is a hand-rolled AWS Signature V4 implementation using only node:crypto. No AWS SDK, no S3 library, no heavyweight dependencies to audit or keep updated.
It runs entirely inside the gateway process—no external scripts, no separate cron daemon, no stopping the gateway to take backups.
Get started
The plugin is open source (under the MIT license) and available now:
Every neocloud in the market right now is winning or losing on the same battlefield: GPUs. Availability, performance, price per hour. That’s the game, and it’s the right game to play.
But there’s a problem compounding underneath it, one that doesn’t show up in benchmark reports or investor decks, and one that customers will eventually force platforms to confront—neoclouds need highly available, performant storage so that GPUs are never waiting on data.
Neocloud customers need more than compute
Cloud storage isn’t adjacent to what neoclouds sell—for buyers, it’s the difference between a complete platform and a partial one. Neocloud customers need:
Somewhere to put a 10PB training dataset before it touches WEKA, VAST, or DDN boxes
Persistent storage for model checkpoints between training runs
A place for production inference pipelines to pull weights from at scale, fast enough that GPU nodes aren’t sitting idle waiting on data
Most platforms know this. The ones that are honest about it will also tell what happened when they tried to solve it: Engineering sprints planned around storage tooling that competed directly with GPU roadmap work. Ops overhead for infrastructure that customers take for granted when it’s working and blame the platform for when it’s not. Capital allocated to storage hardware and the teams to manage it.
The platforms that figured this out first didn’t hire their way through the problem. They stopped building storage and started shipping it.
Introducing B2 Neo
That’s the insight behind Backblaze B2 Neo. We built it in direct collaboration with the neocloud operators already utilizing Backlaze in production. The result is a white label cloud storage backbone that neoclouds can launch as a native extension of their platform. Here’s what that means in practice:
Up to 1Tbps throughput: Storage that keeps GPU clusters fed and AI workflows moving without becoming the bottleneck.
Launch under your own brand: Branded endpoints, partner-controlled pricing, and a native customer experience that keeps the platform front and center.
API-driven provisioning: Provision accounts, manage permissions, and handle billing through existing platform tools without a separate console or manual setup.
17 years of operational maturity and exabyte scale expertise: Enterprise durability and reliability that customers expect, operated by Backblaze so internal teams don’t have to.
It doesn’t require a storage team. It doesn’t compete with the GPU roadmap. And it doesn’t route customers away from neocloud platforms where their workflows slowly migrate away.
Already in production with leading platforms
Multiple neoclouds are already using B2 Neo. It’s infrastructure that’s already handling AI training workloads, high performance compute (HPC) pipelines, and media delivery at scale and the platforms already running it are direct about why they made the call.
One global edge services platform, after a rigorous technical and business evaluation, put it this way: Their customers were demanding cost-effective yet performant storage as their AI business scaled and Backblaze gave them the ability to deliver cloud object storage as a native extension of their own platform without taking focus away from their roadmap.
Rob Strechay, Principal Analyst at Smuget & theCUBE Research, framed it simply:
With B2 Neo as a first-party service offering to neoclouds, I see the advantage for those organizations of being able to turn on cloud storage without the toil and expense of building it themselves. It is a near-instant value-add offering, helping their customers control costs and achieve the ROI of AI faster.
The question for the rest of the market is how many more quarters of DIY storage ops—or hyperscaler dependency—they can absorb while competitors ship that outcome instead.
B2 Neo is available now. If you’re building a neocloud and storage is either a distraction or a gap, I’d encourage you to talk to us.
The Backblaze Flameflower Startup Program is here, and it’s built by people who’ve been burned before (and that’s a good thing for you).
Startups don’t fail because they pick the wrong cloud storage provider.
They fail because everything else is already hard enough, and infrastructure quietly becomes the thing that slows them down, surprises them, or blows up their budget at exactly the wrong moment.
That’s why we’re launching Flamethrower, the new startup program from Backblaze.
It’s not a gimmick. It’s not a lead trap. And it definitely doesn’t bring the “here’s some credits, good luck” energy.
Flamethrower exists for one simple reason: Founders deserve storage infrastructure that helps them move faster, not learn expensive lessons the hard way.
Why Flamethrower exists
Why Flamethrower?
Startups don’t need more friction, they need a way through it. Metaphor-wise, flames have always been a part of Backblaze’s DNA, and we want this program to speak to the strongest parts of that fire: speed when you need it, reliability when it counts, and power to scale without drama.
Flamethrower takes these ideas and applies it directly to startups, burning away the biggest blockers between you and your next milestone.
I’ve spent most of my career in and around startups, as a founder, an operator, a partner, a mentor, and occasionally as the person explaining to a CFO why last month’s cloud bill looked like a typo.
I’ve seen the pattern repeat over and over:
Early teams optimize for speed (correct)
Infrastructure decisions get made quickly (also correct)
Those decisions quietly become very sticky
And later… someone realizes storage costs are now a board-level discussion
Flamethrower is designed to meet teams before that moment, making your architecture deliberate, not accidental.
Not with abstract promises, but with:
Real infrastructure used in real production environments
Credits that actually help you get to product-market fit
And access to real, live humans who understand what it’s like to build under pressure
Documentation should be written by people who actually use the product
And success shouldn’t be punished with surprise bills
That mindset is exactly why Flamethrower fits here.
This isn’t a side project. It’s an extension of how Backblaze already works with developers and builders, just with a little more gas on the fire (if you will).
I’ve spent years building and running startup programs, developer ecosystems, partnerships, and learning, sometimes painfully, what not to do. I’ve been on the receiving end of “exciting programs” that turned out to be mostly slide decks.
Flamethrower is my attempt (with a very smart team) to build the kind of program I wish existed when I was earlier in my career: practical, honest, and actually useful.
No heroics. No silver bullets. Just support where it counts.
This year marks 13 years of collecting Drive Stats data. Thirteen is an unlucky number (to some), but we count our lucky stars (or perhaps our lucky stats?) that we’ve had 13 years of this experiment.
The traditional 13-year anniversary gift is lace—intricate, impressive, and vulnerable to a snag if you don’t plan ahead to protect the pattern. Systems, like lace, don’t survive by pretending there are no points of vulnerability. When it comes to our infrastructure, we want to build with the snags in mind to create something durable, and the Drive Stats series is always seeking to publish and provide data so that you, too, can go the distance with your drives.
This year-end Drive Stats report looks at Q4 2025, the full year, and the lifetime view with that in mind. I think you’ll find the same things we do: over time, the patterns matter more than any single strand (or drive, to run this lace metaphor into the ground once and for all). Let’s look at the stats.
Drive Stats is here for you
Drive Stats is not a situationship. We’re a conversation and a relationship—to the data. Join the Drive Stats team for our regularly scheduled webinar to walk through the 2025 annualized failure rates, break down the data for interesting trends, and get the latest from the Backblaze drive fleet happenings.
Drive Stats: The digest version
Q4 2025 hard drive failure rates
As of the end of 2025, Backblaze was monitoring 341,664 drives used to store data. For our evaluation, we removed from consideration 4,013 boot drives and 459 hard drives, as they did not meet the criteria to be included. We’ll discuss the criteria we used in the next section of this report. Removing these drives leaves us with 337,192 hard drives to analyze. The table below shows the annualized failure rates for Q4 2025 for this collection of drives.
Backblaze Hard Drive Failure Rates for Q4 2025
Reporting period October 1, 2025–December 31, 2025 inclusive Drive models with drive count > 100 as of December 31, 2025 and drive days > 10,000 in Q4 2025.
Note and observations
New drives!
Seagate ST16000NM000J 16TB, with 112 drives
WDC WUH722626ALE6L4 26TB with 1,201 drives. Our first 26TB drive!
The honor roll:
HGST HMS5C4040BLE640 4TB: 1 failure
Seagate ST8000NM000A 8TB: 0 failure
Seagate ST12000NM000J 12TB: 1 failure
Seagate ST16000NM000J 16TB: 1 failure
Seagate ST16000NM002J 16TB: 0 failure
WDC WUH722626ALE6L4 26TB: 1 failure. Shoutout to the new kid—starting off strong!
Red flags:
HGST HUH728080ALE600 8TB: 10.29%
Seagate ST10000NM0086 10TB: 5.23%
Toshiba MG08ACA16TEY 16TB: 4.14%
We talked about two of these drives last quarter, and what we said about the Seagate still holds true—we’re seeing end of life activity with this drive. But, let’s dig in on the 8TB HGST and 16TB Toshiba and see what’s going on.
HGST HUH728080ALE600 8TB
There’s always some digging to be done when we see a double digit failure rate, especially on a drive that, in the past year, hasn’t had terrible failure rates (despite the fact that it’s about 7.5 years old).
It’s worth contextualizing, first, that the total drive count of this model is 1,073, which equates to less than one Vault. (A standard Vault has 1,200 drives.) While Vaults aren’t always the same drive model, especially with older drives, in an ideal world, those Vaults would be uniform. So, in this case, we’re dealing with drives that are all hanging out in the same location in a data center, which means we could be working with environmental factors like a change in temperature or airflow.
By the time Drive Stats data gets to me, of course, lots of smart people have already seen the disturbances in the force, so to speak. When I dug into the data center work tickets, it turned turned out that folks had already ruled out temperature as a factor—the working theory at the moment is that the drive could be sensitive to vibration, but given the age of these drives, we decided to just flag them for our normal CVT migration process.
Toshiba MG08ACA16TEY 16TB
We talked about this model last quarter because it clocked in at a 16.95% AFR (!!). Our investigation turned up some collaborative (and routine) firmware work with Toshiba, and at that time, we predicted that these failure rates would normalize once again. We’re still a little high, but that’s likely a function of rolling out the work. As predicted, this is a healthy normalization.
Defining the relationship, aka setting some boundaries
We’ve covered the reasons that we’ve designed these exclusions in past reports, but here’s the quick and dirty:
Period
Drive Count
Drive Days
Quarterly
> 100
> 10,000
Annual
> 250
> 50,000
Lifetime
> 500
>100,000
Regardless of whether or not a given drive model is included in this article’s charts and tables, all of the line item data is included in our Drive Stats dataset which you can download by visiting our Drive Stats page.
2025 Annual hard drive failure rates
As of the end of 2025, Backblaze was monitoring 349,462 hard drives used to store data. We removed 4,176 boot drives and 1,090 hard drives from consideration as they did not meet the annual criteria we have defined. This leaves us with 344,196 drives divided across 30 different drive models. The table below shows the AFRs for 2025 for this collection of drives.
Backblaze Hard Drive Failure Rates for 2025
Reporting period January 1, 2025–December 31, 2025 inclusive Drive models with drive count > 250 and drive days > 50,000 in 2025
Notes and observations
The annual AFR is down: This year finishes strong at 1.36%, down from 1.55% in 2024. Still those paying attention to the quarterly AFR have seen some volatility in that number.
Nobody made it out unscathed: There are zero 0 failures.
But, let’s talk about it: These are the drives that averaged less than two failures per quarter (though, not necessarily evenly distributed when you look at the data).
HGST HMS5C4040BLE640 4TB: 5 failures
Seagate ST12000NM000J 12TB: 4 failures
Seagate ST14000NM000J 14TB: 7 failures
Seagate ST16000NM002J 16TB: 1 failure
Toshiba MG09ACA16TE 16TB: 3 failures
WDC WUH722626ALE6L4 26TB: 1 failures.
Note that this drive is in its first quarter of life, so it’s hard to call this significant yet.
And, all those drive tickets and models mean lots and lots of work—we wrote a whole article on that front, but here’s a breakdown of hours spent in each data center.
And here’s an even more interesting slice, from a drive perspective:
Yes, you’ll see some funky drive sizes on that list; it’s inclusive of all of our drives, not just the hard drives we include in this report.
Comparing Drive Stats for 2023, 2024, and 2025
Let’s take a look back at the previous years’ annual AFRs to get a sense of how 2025 compares:
Three Year Comparison of Annual Backblaze Hard Drive Failure Rates
For drive models with > 250 drives as of 12/31/25 and drive models with > 50,000 drive days in 2025 Data for each year is inclusive of that year.
Notes and observations
The annual AFR is down to 1.36%. We haven’t seen those numbers since 2022 (1.37%). Cool!
Slicing our data by drive size shows how impactful the shift to high capacity drives really is: based on the current quarterly data, our drive size breakdown looks like this:
0–12TB: 25.13%
14–16TB: 52.06%
20TB+: 22.81%
This is an already long report, so in the interest of time, we’ll just say this: There are multiple factors that go into how and why things are changing, including the average age of drives within our cohort, how much drive technology has improved over the years, how drives on the market have gotten bigger over time while the cost per GB has also dropped, and how the current demand for drives has been changing some of those things.
If that sentence sounds confusing, welcome to the world of enterprise drive buying. But, as always, we have to contextualize the real data we see with the way we source and use drives.
Lifetime hard drive failure rates
Backblaze Lifetime Hard Drive Failure Rates
Reporting period ending December 31, 2025 inclusive Drive models with > 500 drives and > 100,000 lifetime drive days
Notes and observations
Ol’ faithful: Lifetime AFR is 1.30% this quarter, and there’s been no significant change in that number for quite some time.
Say hi to the new guy: The Toshiba MG11ACA24TE 24TB made the cut for the lifetime table. Last quarter, we deployed another 2,400 of these, bringing us to 4,806 drives total.
The Hard Drive dataset (and beyond)
Thank you, as always, for making it through ~2,500 or so words to examine the fun side of data. Here’s our standard fine print:
The complete dataset used to create the tables and charts in this report is available on our Hard Drive Test Data page. You can download and use this data for free for your own purpose. All we ask are three things:
You cite Backblaze as the source if you use the data;
You accept that you are solely responsible for how you use the data, and;
You do not sell this data itself to anyone; it is free.
If you’re a new Drive Stats fan, consider signing up for the newsletter. If you’re not ready for that kind of commitment, sound off in the comments section below or reach out directly to us to let us know what you’re working on. Happy investigating!
As data footprints swell and multi-cloud strategies become the norm, the complexity of managing object lifecycles—from initial creation to eventual archival or deletion—can introduce significant risk and operational overhead. To help our customers solve for this, we recently announced support for lifecycle rules through S3-compatible APIs.
While the previous post focused on what the feature enables and why it matters, this follow-up will look at how lifecycle rules work at a deeper level and what to keep in mind when using them in production.
Why S3 compatible lifecycle rules matter
Let’s quickly refresh your memory about why this feature matters. Many customers already rely on lifecycle rules in Backblaze B2 to manage storage costs and data retention. These rules automate actions like deleting old objects, hiding previous versions, or cleaning up incomplete multipart uploads.
By adding S3 compatible support for lifecycle rules in Backblaze B2, it allows you:
Lift and shift migrations from AWS S3 to Backblaze B2
Reuse of existing tools, xml configurations, scripts, applications & infrastructure as code
Predictable behavior across environments as part of multi-cloud strategy
API surface area and XML structure
Lifecycle rules are managed using three APIs:
PutBucketLifecycleConfiguration
GetBucketLifecycleConfiguration
DeleteBucketLifecycleConfiguration
These APIs accept and return XML documents that follow the AWS S3 lifecycle configuration format. From a client perspective, this behaves the same way it does on S3, including rule IDs, status flags, filters, and actions.
Example put lifecycle request
Below is a simple example that hides objects under the logs/ prefix after 30 days.
PUT /?lifecycle HTTP/1.1 Host: my-bucket.s3.us-west-004.backblazeb2.com Content-Type: application/xml
At evaluation time, B2 walks object versions in order and applies rules like this:
Pseudo code:
for each object in bucket: for each version of object with data prefix: if version is non current: if age_in_days >= NoncurrentDays: delete version
For current versions, expiration works differently.
Expiring the current version
When a lifecycle rule expires the current version, B2 creates a hide marker instead of deleting data immediately.
This matches S3 semantics and preserves version history.
current version expired | v hide marker created | v current version becomes non current
Overlapping and nested prefix rules
Backblaze B2 supports multiple lifecycle rules on the same bucket, including overlapping and nested prefixes.
For example, you might configure:
A general rule for logs/ that deletes objects after 365 days
A more specific rule for logs/audit/ that deletes objects after 90 days
When rules overlap, the configuration with lowest value is applied to save cost to you. This mirrors S3 behavior and allows fine grained control without duplicating buckets.
Matching logic:
object path: logs/audit/2024/01/file.json
matching rules: - logs/ - logs/audit/
selected rule: - logs/audit/ because it has lowest value, 90 days
Multipart upload cleanup
Lifecycle rules can also be used to abort incomplete multipart uploads if not completed in a certain number of days. This is implemented by tracking the initiation time of multipart uploads and periodically removing uploads that exceed the configured threshold. This helps prevent abandoned uploads from consuming storage indefinitely.
Below is an example rule to delete multipart uploads that are not completed after seven days after starting the upload process.
Multipart uploads are tracked with their initiation timestamp.
Pseudo code:
for each multipart_upload: if now - initiation_time >= DaysAfterInitiation: abort upload delete uploaded parts
Lifecycle execution model
Lifecycle rules are not executed in real time. Instead, they are evaluated by background processes that scan eligible objects and apply actions asynchronously.
Important characteristics:
Rules are not evaluated in real time
Execution is eventually consistent
Large buckets may take multiple passes to fully apply changes
This design allows lifecycle processing to scale across billions of objects efficiently without impacting foreground operations.
High level execution flow:
scan bucket periodically | v identify eligible objects | v apply lifecycle actions (hide and/or delete) | v record progress and continue
Error handling and validation
Lifecycle XML is validated using S3 compatible rules:
Invalid combinations of actions are rejected
Missing required fields return errors
Unsupported actions return descriptive failures
While error messages may differ slightly from AWS, the validation logic follows the same constraints.
Compatibility considerations
While the goal is strong S3 compatibility, there are still some things to keep in mind:
Not all S3 lifecycle actions are supported yet
XML validation follows S3 rules, but error messages may differ slightly
The underlying storage model of B2 can affect timing and visibility
We recommend testing lifecycle rules in a non production bucket before rolling them out broadly.
Final thoughts
Adding S3 compatible support for lifecycle rules on Backblaze B2 was all about making migrations simpler and letting customers reuse existing automation with confidence. It behaves the way you expect while benefiting from B2’s internal scalability.
If you already manage lifecycle rules using S3 APIs, those same configurations can now run on Backblaze B2 with minimal or no changes.
Welcome to our second quarterly Network Stats report covering Q4 of 2025. Along with Drive Stats and Performance Stats, Network Stats pulls back the curtain on real-world infrastructure data, particularly how network-level analytics reflect emerging AI industry trends and usage patterns.
Get more Network Stats (and the details of the dataset)
If you are curious about what metrics we’re recording and how we classify data in this series, check out the details outlined in our Q3 2025 Network Stats report.
One of the roles of the Network Engineering (NetEng) team at Backblaze is to monitor how traffic moves into, out of, and across our platform—not just day-to-day, but over time as customer behavior and industry dynamics evolve. Right now, few forces are reshaping networks faster than AI.
With the launch of B2 Overdrive in April 2025, we built a direct, high-performance path between our storage layers and neoclouds where processing, inference, and modeling take place. It has given us a front-row seat to the impact of AI and how network behavior is changing with it. This quarter, in addition to our regular data analysis, I’ll walk through where AI-driven traffic is concentrated, how ingress and egress patterns showed up, and what the findings say about where AI infrastructure might be headed next.
Continue the conversation
Join us live for the Q4 2025 Network Stats webinar Wednesday, February 4, 2025 at 10:00 a.m. PT / 1:00 p.m. ET. We’ll explore where AI traffic concentrates, how high-magnitude data flows behave, and what early indicators suggest about the future of AI-native infrastructure design.
Can’t make it live, or reading this article after-the-fact? Sign up anyway and catch the recording on demand.
Brave new market
AI workflows don’t just need a place to store data, they need to be able to move it quickly, easily, and nearly constantly for short bursts. Large, multi-petabyte datasets are ingested, transformed, exported for training, pulled back for evaluation, and periodically refreshed as models evolve.
Backblaze plays a key role at both ends of that lifecycle. We serve as a durable storage layer for the initial data ingestion, and as the high-throughput source feeding model training, evaluation, and validation to whatever best neocloud is suitable at the moment. Once that model has been trained, it needs to be stored, served, and periodically retrained, where we serve as the storage medium.
This quarter, we saw a large amount of traffic between Backblaze, neoclouds, and traditional hyperscalers for processing concentrated across the months of June to November. This reflects large-scale ingestion events followed by intensive data manipulation and model-related egress.
From a network perspective, this represents a meaningful shift from diffuse, internet-style traffic patterns to large, high-bandwidth flows between a smaller set of endpoints typical of AI-centric infrastructure.
The neocloud slice
The defining theme of the quarter is “new:” new AI-oriented workflows, new traffic patterns, and leading indicators of new infrastructure trends.
The stacked area graph below shows total traffic by network type over time. While content delivery network (CDN), hosting, and internet service provider (ISP) traffic stayed largely within historical norms reflecting steady-state usage patterns like content delivery, web hosting, and traditional backup workflows, two slices stand out:
Migration traffic: We saw a notable increase in migration traffic from August through October. This classification reflects an influx of data into our network over fiber connections we have in the data centers to cost effectively migrate large amounts of data over private links, not using the public Internet.
Neocloud traffic: We saw a sharp increase in July through November, peaking in October.
Monthly view of all bits transferred to each network type
What do we think is happening? Taken together, these patterns suggest a familiar AI lifecycle: large datasets consisting of assets like images, videos, and metadata are ingested and consolidated then exported for training and experimentation. Now, those assets can be periodically updated as new assets are added and generated models and stored. We see that heading into the new year, the overall baseline has increased indicating a new normal.
Quick terminology refresher
Regions
US-West: Our largest and longest-running region
US-East: Region with the most observed proximity to neocloud infrastructure
CA-East: Our newest region in Canada.
Network Types
CDN: Networks that use Backblaze as an origin store for content delivery
Hosting: Traditional hosting providers that runs workloads like physical or virtual servers for web, database, or application tasks
Hyperscaler: Large, traditional cloud providers
ISP Regional: Local or regional ISPs, think of these as the “last mile” paths as these networks are very close to customer equipment and efficient
ISP Tier1: National or international ISPs that carry our traffic long distances
Neocloud: AI -focused compute networks
Migration: Network links that we use for large-scale data onboarding
Heatmaps: Where AI traffic concentrates
To better understand where AI activity is happening, we thought it would be interesting to isolate the different Backblaze regions and to view concentrations of metrics visualized through heatmaps. We’re going to look at the following three dimensions:
Total traffic volume: Where did we send and receive the most traffic?
Magnitude: Where were the data transfers with the most bits per unique IP address?
Uniqueness: What does the number of distinct IP addresses look like?
Heatmap #1: Where did we send and receive the most traffic?
Unsurprisingly, US-West ISP-Regional traffic dominates in total traffic volume. This region has the largest data center footprint behind it, with connectivity to internet exchanges (IX) such as Equinix-IX that were brought online in 2023. Internet exchanges bring us closer to consumer networks, where we can deliver traffic with lower latency.
More interesting, however, is the US-East neocloud concentration. Our flow data shows neocloud activity clustering in regions including Chicago, Dallas-Houston, Denver, New York, Northern Virginia (Reston/Ashburn corridor), and Atlanta—skewed more towards the East Coast where there’s dense AI compute availability.
From a performance standpoint, this makes sense. It’s important to keep latency (the time between the source and destination) lower to achieve consistent high bandwidth rates for AI data transfers. For now, that gravity is pulling activity towards the East coast.
Total number of bits transferred across our regions to each network type
Will neocloud traffic concentrations shift over time? Since this is our first quarter with a full dataset, it’s a bit early to draw long-term conclusions. But this is exactly the kind of trend we’ll be tracking. Stay tuned for future Network Stats reports.
Heatmap #2: Where were the data transfers with the most magnitude (bits per IP address)?
Another metric we record is bits per IP or what we termed in our last report “magnitude.” This combination of the amount of traffic transferred with how many actors are involved per network is a good proxy to measure how heavy or impactful individual data flows are. In short:
High volume, many IPs: Easier to distribute and load-balance across infrastructure. And many source and destination pairs means that we can traffic engineer at the WAN layer, sending some traffic over one provider and some over another.
High volume, few IPs: More difficult, but more interesting, from a NetEng perspective.
Magnitude transferred across our regions to each network type
With B2 Overdrive, we routinely support client transfers starting at 100Gbps up to 1Tbps of throughput.These high-magnitude flows show up clearly in the data, especially in regions serving AI-heavy neocloud endpoints. Seeing these patterns emerge in the data validates that customers are actively using the platform the way it was designed.
Heatmap #3: How many unique addresses do we interact with?
Uniqueness—measured by the number of distinct IP addresses per network type—adds another dimension to the story.
US-West shows the highest overall uniqueness, driven by its larger number of data centers and mix of workloads.
Neocloud traffic, by contrast, tends to involve fewer, more persistent endpoints, consistent with AI pipelines that rely on stable, long-standing connections between storage and compute.
This contrast reveals a broader trend: AI networking is less about many-to-many communication and more about sustained high-throughput relationships between specialized systems.
Communication uniqueness across our regions to each network type
Summary: Early indicators of an AI-native network era
This quarter represents an early but important snapshot of how AI is reshaping network behavior:
AI-driven traffic is concentrated and heavy (not groundbreaking news by any means, but interesting to see it played out on a network).
Neocloud connectivity is a defining feature of data movement today.
Data gravity is pulling storage, compute, and network design into tighter alignment.
This is our first look at these patterns specifically. As we gather more quarters of data, we’ll be watching closely to see how cyclical neocloud activity becomes, how regional concentrations shift, and how the growing ecosystem of AI-focused ISVs continues to change the shape of the network.
Quarter over quarter data
Last quarter we started capturing data and metrics that we were interested in tracking over time. This represents our first full quarter of data as we only started tracking in August of 2025, so it’s still early to start to see trends, but we’re including the visualizations for fidelity.
First let’s take a look at where all our traffic goes from a global perspective with an updated view of last quarter.
Sankey diagram of all August ingress and egress traffic grouped by type of network
Traffic to other clouds has increased (36.2% to 49.6%) since we last reported in August of 2025, with a slight decrease (19.8% to 18.4%) in Neocloud destinations, but a large increase (3.5% to 18%) to hyperscalers. It’s too early to call these things statistically significant trends or patterns that impact the cloud storage industry broadly, because they’re reflective of what types of customers Backblaze specifically has and our sampling range is only a quarter. That said, we do see an overall increase in cloud to cloud traffic, but the higher percentage to the type of clouds rotated from last quarter.
Next, let’s look at the magnitude of our network traffic based on the category of the traffic destination. As a reminder, magnitude represents the amount of traffic transferred with how many actors are involved per network.
Next, to be consistent with our previous report, we’ll look at magnitude on a linear scale.
With more datapoints, we can clearly see the magnitude of the neocloud and hyperscaler transfers when compared to other network types. As above, it’s a bit early to claim concrete quarter over quarter patterns, but we’ll keep monitoring and updating the dataset.
What’s next?
Next quarter will be the first where we have true quarter over quarter data to analyze, and we’ll be back with more on how AI-driven flows change quarter over quarter. And as we get more data, we’re interested in looking at other trends like IPv4 vs. IPv6 traffic, cross-cloud connectivity trends, and revisiting the concentration analysis we did this quarter.
Anything specific you want to see? Let us know in the comments or reach out to our Evangelism team. Or, keep up-to-date with the latest technical content with our Developer Newsletter.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
ISP-Regional traffic continues to be a hotspot on the heatmap, as expected. This region has the largest footprint behind it and connections to internet exchanges (IX). This quarter, with a lull in neocloud and hyperscaler traffic over the winter period, we saw an increase in traffic to our CDN partners. The amount of traffic to CDN networks in the US-West, US-East, and EU-Central regions all increased quarter over quarter.
ISP-Regional traffic dominates in total traffic volume. This region has the largest data center footprint behind it, with connectivity to internet exchanges (IX) such as 
