Post Syndicated from Performance Stats Team original https://www.backblaze.com/blog/backblaze-performance-stats-for-q3-2025/

In cloud storage and compute, “less is more” no longer applies. As data grows and expectations rise, businesses need performance, reliability, and real value—not just lower costs. It can be tempting to rely solely on hyperscalers like AWS, but the challenge is understanding where cloud performance truly meets value.

That’s why Backblaze is launching Performance Stats, our newest stats content built on the transparency of 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. (So, feel free to argue with us in the comments.)

By publishing everything—strengths, weaknesses, and all—we’re hoping to give AI leaders, app developers, and decision-makers a clear, honest view of how Backblaze and other cloud storage providers perform in the wild.

Cutting through the noise on cloud performance 

Frankly, it’s super frustrating how opaque performance metrics can be, and how many misleading storage reports are out there. Building accurate tests is complicated for a lot of reasons—so many factors are contingent on things that product builders and even end users control, like where and how data is stored, where it’s being served to end users, and so on. And, most published content on this topic has been tested from inside the cloud storage company’s architecture, which means that they’d give themselves preferential results.  

While our report may not be perfect, our transparent approach—particularly publishing the testing methodology—will allow us to mitigate some of those concerns. 

We want to take a hard look at performance on a level playing field for two reasons: 

1. 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. 
2. 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. 

Without further ado, here are the results

We ran performance testing for Backblaze B2, AWS S3, Cloudflare R2, and Wasabi Object Storage. These tests were conducted using Warp, an open-source S3 benchmarking tool for cloud object storage performance. We’ll expand on the methodology after we get into the numbers. 

Key findings:

• While AWS S3 demonstrates the lowest average download speeds across the board, the hyperscaler didn’t win on sustained download throughput measurements. Five minute single- and multi-threaded benchmarking tests showed AWS winning on only one out of eight sustained throughput tests, indicating that there’s much more to the story than average download speeds. Meanwhile, Backblaze won in six out of eight categories, with Wasabi coming in first on the remaining test. (That being said, it’s wise to take this with a grain of salt given the small cohort in this initial dataset—more robust testing may show different results.)
• Sustained throughput testing shows the most differentiation at small file sizes for both single and multi-threaded testing. For example, in multi-threaded upload benchmarking for the 256KiB file size, our highest value was 580% higher than the lowest. In single threaded upload benchmarking for the same file size, the highest value is 700% higher. Download throughput showed 247% and 304% in multi- and single-threaded tests, respectively. Small file size testing can have interesting impacts on overall performance—these files have the most overhead, and are typically more likely to show latency. 
• Backblaze B2 demonstrates the fastest average upload speeds for small file sizes, with AWS S3 leading for larger file sizes. And, similar to downloads, the story becomes more nuanced when we look at sustained upload throughput, where Backblaze leads for both the smallest (256KiB) and largest (100MiB) file sizes on multi-threaded tests with Wasabi taking the lead in the mid-range.

And, here’s a jump-to if you want to quickly reach each test: 

• Upload averages (in milliseconds)
• Five minute multi-threaded upload test
• Five minute single-threaded upload test
• Download averages and TTFB (in milliseconds)
• Five minute multi-threaded download test
• Five minute single-threaded download test

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 (i.e., it represents a faster result). Note that we do not have data for Wasabi: Wasabi does not allow users to run HTTP requests for the first 30 days of a new account period, and when we ran this report, our testing account was still within that time period.

In each of the charts, we’ve outlined the “winner” in green for each category for easy readability. 

Backblaze B2 wins for small files, coming in at 12.11ms, and AWS S3 leads for 2MiB and 5MiB files, coming in at 76.79ms and 201.40ms, respectively. Whether or not these numbers are inherently “good” or tolerable depends on quite a few factors—we’ll run through some examples comparing use cases to where we see Backblaze succeeding later in the report.

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—rather, it tells us the sustained amount of data you can push to a cloud storage provider in five minutes. 

Interestingly, we have a pretty large spread between our highest and lowest values, most stark amongst the smallest files where Backblaze B2 demonstrates the highest sustained throughput at 163.80MiB/s and Cloudflare R2 demonstrates the lowest at 24.10MiB/s. 

This is important because the strength of object storage is that it lets you run concurrent operations to read many ranges of bytes in the same file. Moreover, thread operations are a configurable element of most cloud storage accounts (though too many concurrent operations can trip rate limits that are dependent on the provider).

So, when we think about contextualizing with the average time to a file upload completion, the task includes making the request, the handshake between requester and server, routing the request through the cloud storage provider, then time it takes to read all data, and then notification that your upload is complete. 

Threading lets you run the actual process of the return of information concurrently—so while file overhead (handshake) should be relatively consistent, you can get quite a bit faster on large file uploads. And, even when you have consistent results on file overhead, networking paths can make a difference on delivery times. While we can consider networking routes mostly stable (especially for synthetic performance testing), it’s certainly not a guarantee. Peering policy changes, network maintenance and/or outages, and CDN usage can all affect your routing day to day or month to month. 

Changing the view a bit, we see some interesting shapes when we plot each providers’ improvement as file sizes get larger:

It’s intuitive that you’d automatically push more data as file sizes get larger, but the shape of each’s improvement is a stark contrast. The rate of increase (which you can see in our trendlines as the slope) isn’t constant, and we see Backblaze and AWS showing consistently better performance at the higher file sizes. Wasabi tracks with that growth in the smaller file sizes, but falls off at the 50MiB and 100MiB. Meanwhile, we see Cloudflare returning the lowest net values, while flattening out at smaller file sizes as well.  

In most performance data, you expect a logarithmic relationship between data points—and so comparing their different shapes—when the trendline flattens out and/or when it deviates from an ideal logarithmic scale—can be telling. You can define an expected logarithmic curve using an average of all providers, then compare each provider’s residuals (how far above or below that curve it sits). We’ll save that analysis for another day, and a more mature dataset. 

It’s also interesting to look at data point clustering by file size. As our dataset matures over time and as we add providers, clustering in these charts start to tell a story. If you want a quick idea of good, better, best and you don’t have a large enough cohort for a true tiered definitional schema, it’s a good visual shortcut—you can easily see if different providers’ results are spread out or if they cluster together at a specific level of performance. The winners for each test are labeled in green.

And, as we said above, in all cases (and one of the most frustrating parts about collecting performance stats) is that your mileage may vary—you always want to compare the needs of your customers and product to the performance you need and how much it costs you. 

Five minute single threaded upload

Once again, higher is better in this result, and it measures the sustained amount of data you can push to a server based on file size. As a reminder, multi-threading allows you to concurrently read a single file; while single threading is one, sustained process from start to finish.  

Backblaze B2 again leads in small file sizes, with AWS S3 leading for 5MiB files and Wasabi for 50MiB and 100MiB files.

As above, here’s the trendline: 

And, like in the multi-threading results, we can look at the clustering in each file type size: 

Download comparisons

This test shows the average time in milliseconds it takes to download a file. Averages were taken across a month of data and for three different file sizes. 

A reminder that lower is better in this test as it represents a faster result, and there’s no data for Wasabi in this series due to limitations on HTTP requests within the first 30 days of opening a new account.

AWS S3 leads across the board on this test, with Backblaze B2 taking second and Cloudflare R2 taking third consistently.

And, it’s worth separately tracking TTFB because TTFB is a good, but not sufficient statistic when we’re interpreting results.  

Why isn’t this datapoint sufficient to fastest speeds? Not only does TTFB conflate many parts of your networking layer (so it can be affected by things like connection reuse policies), but it’s also such a small part of the overall transfer time and highly variable based on environment. So, its use is really in conversation with the sustained throughput numbers.

Cached vs. uncached downloads (Backblaze only) 

We were also curious to see if caching within our own network would show up, and, if so, we’d want to make sure we weren’t unintentionally giving ourselves a favorable stance. So, we ran a series of tests for cached and uncached downloads by including the header X-Bz-Flush-Cache-First=true.

We do see slightly slower speeds in uncached downloads, but they’re likely a result of the same factors anyone externally hitting our system would see. Additionally, during the course of our testing, Backblaze made cacheless downloads the default behavior for our architecture—so, it will be interesting to monitor this statistic going forward. 

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.

Backblaze B2 leads for 256KiB, 50MiB, and 100MiB file sizes. AWS S3 has a slight advantage for 5MiB files. 

And, let’s give ourselves the same charts as our above upload tests for consistency’s sake. Here’s the trendline:

While AWS and Backblaze track closely for the 256KiB and 5MiB file sizes, Backblaze wins out at 50MiB and 100MiB. Meanwhile, Cloudflare lags at the smallest file sizes, but shows rapid improvement, peaking at the 50MiB file sizes. Interestingly, this is arguably Wasabi’s weakest showing compared to all other sustained throughput testing, though they have strong results at the 256KiB file size and a respectable showing at the 5MiB file size. 

And here’s the per-file size clustering:

Five minute single-threaded download throughput

Again, in these tests, a higher result is better, as the result represents more average data being downloaded in the five minute time period. 

Here, Wasabi wins for 256KiB files, and Backblaze wins for 5MiB, 50MiB and 100MiB files. Note that this is a solid trend for Wasabi in the 256KiB file sizes—they came in second in the multi-threading download testing, as well as both single and multi-threaded upload testing.

And here’s 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 four vendors. Upload tests measured the following file sizes:

• 256KiB
• 5MiB
• 50MiB
• 100MiB

Download tests measured:

• Time-to-first-byte (TTFB)
• Total time to download the following file sizes:
  • 256KiB
  • 5MiB
  • 50MiB
  • 100MiB

Tests run in five-minute profiles to observe consistency over time, and we ran both single and multi-threaded download and upload tests. From a practical perspective, what’s happening is that we’re pushing repeated requests to a cloud storage provider as many times as we can for five minutes. 

All tests originate from a Vultr-hosted Ubuntu virtual machine (VM) located in the New York/New Jersey area, routing through Catchpoint’s network into object storage regions located generally in US-East. 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 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.
• 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.

Each of these limitations points toward future testing opportunities. Here’s what’s next on our testing roadmap:

• Regional expansion: Extend current US-East tests to US-West and EU regions using equivalent test setups.
• Vendor expansion: Extend testing to more vendors, including Google Cloud Platform and Azure.
• File size sensitivity testing: Investigate performance across a wider range of file sizes, including 100MiB+ objects. This will help clarify where different architectures favor small-object throughput versus sustained large transfers.
• Traffic rate & throttling analysis: Incorporate monitoring for request-per-minute and total-bytes-transferred metrics to detect possible provider-level rate limiting. We’d love to invite vendors to validate thresholds and eliminate false negatives.
• Concurrency patterns: Test multiple thread and connection strategies to model real-world transfer concurrency, especially for use cases involving parallel uploads or downloads.
• Benchmark visualization: Transition from CSV data collection to Grafana dashboards, enabling continuous visualization of test results and performance drift over time. 

Performance is an evolving target, and so is our testing methodology. Each round of analysis helps us not only understand how Backblaze performs in context, but also refine how we measure, compare, and communicate that performance. Our goal remains the same: make the data real, repeatable, and useful.

What this means for real-world use cases

Based on the results we’ve shared here, there’s plenty of room for argument around the value of different performance profiles. But, continuing our theme of transparency: Since we’re transparent about our performance, warts and all, we’re going to be transparently candid in the areas where think the Backblaze platform is showing some nice results:

• AI/ML inference: Our strong read latency and throughput make Backblaze ideal for inference workloads that need to pull model artifacts, inputs, and outputs quickly. For example, when a service like Hugging Face or Runway ML feeds an image into a convolutional neural network, lower read latency directly translates to faster inference delivery.
• Feature stores & embedding lookups (AI/ML): Optimized small-object reads and efficient small writes support rapid lookups and occasional updates common in vector databases and feature stores like Feast, Qdrant, Pinecone, or Weaviate.
• LLM-based retrieval-augmented generation (RAG) systems: RAG systems store many small document chunks that are written once and read repeatedly, so our read-optimized performance accelerates retrieval of document chunks or embeddings, improving response times for large language model applications. Vectorized databases are also a hot topic right now for good reason—they’re changing patterns around file sizes and retrieval patterns in RAG applications and LLM training. 
• Log & event analytics (SIEM, IoT, etc.): Competitive small-write performance and fast reads make Backblaze well suited for log aggregation and analytical querying with tools like Loki, Fluentd, Vector.dev, and OpenObserve once data is ingested.
• Interactive data lake querying: Consistent throughput and fast download speeds deliver responsive querying and exploration for business intelligence (BI) and ad hoc analytics workloads.
• CDN origin: Excellent read throughput, stable performance, and free egress make Backblaze a high-value choice for powering content delivery at scale.

As discussed, 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. 

That means that when we share results like this, it enables you to interpret which provider is a better fit for your different types of workflows.

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. 

And, there’s a layer of this that’s always going to come down to design decisions. For example, we’ve talked about some of the logic behind where our architecture knows which server to store data on. Basically, our system chooses to store a new file based on the available space of each server. So, if we have a server that has 40% space available, it would receive 40% of the incoming storage writes. (That’s a bit of an oversimplification, but you get the idea.) 

Other cloud storage providers might prioritize, say, randomness in their write architecture. When a request would enter their system, the routing protocol would say, “Hey, we haven’t written to this server over here in a while,” and write it in that sector. It’s a different choice that can have a subtle ripple effect across different aspects of storage architecture.

What’s next?

Our performance story is one of steady, measurable progress. We’re not optimizing for a single headline number; we’re building toward consistent reliability across diverse workloads. That’s why we test openly, publish what we find, and continuously refine how we measure.

Looking ahead, our next Performance Stats report will continue to share these findings quarterly, which will give us all a more mature dataset to work with, and will expand testing. This isn’t just a transparency exercise for us, it’s a commitment to the developers and teams building on Backblaze: you deserve data you can trust—and we intend to keep earning it. 

We’d love it if others—third parties and our competitors—also got involved, but we’ll see how things evolve. For now, feel free to let us know if these tests work for you. 

Disclaimer:
The performance data and comparisons presented here are based on tests conducted by Backblaze under the specific environments, configurations, and conditions described in this post. Actual results may vary depending on network conditions, workloads, geographic location, and other factors.

Backblaze has published its testing methodology so others can replicate or challenge the results; however, Backblaze makes no representation or warranty that its tests capture all possible variables or configurations. The information is provided for general informational purposes only and does not constitute a guarantee of future performance. In addition, the information in this post is based on data available at the time of publication, and Backblaze reserves the right to update or revise this information as new data, testing methodologies, or performance results become available.

All product names, trademarks, and registered trademarks are property of their respective owners. References to third-party products or services are for identification purposes only and do not imply endorsement or affiliation.

The post Backblaze Performance Stats for Q3 2025 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/5-tools-to-integrate-object-storage-and-kubernetes/

It’s no secret that Kubernetes is the de facto container orchestrator for scaling containerized applications. As the Backblaze team gets ready to head to KubeCon North America, we’ve been exploring the ecosystem of tools and integrations that make it easier to store application data in S3 compatible object storage.

From workarounds that make an object storage bucket behave like a persistent volume to cluster backups and early Cloud Native Computing Foundation (CNCF) storage projects we’re excited to watch, here’s a quick guide to making object storage services like Backblaze B2 Cloud Storage work (as close to) seamlessly with your Kubernetes clusters.

Mountpoint for Amazon S3 CSI Driver

AWS Labs released the mountpoint for Amazon S3 container storage interface (CSI) driver to allow Kubernetes clusters to access files in object storage through a file system interface. Essentially, this mountpoint disguises S3 compatible object storage as a persistent storage volume so the Kubernetes cluster can access your object storage without the need for another tool or integration. This also works with other S3 compatible storage services, including Backblaze B2. Check out our GitHub repo for step by step instructions on how to deploy a sample application to test with B2, or see this in action during our upcoming webinar, The State of K8s + S3 Compatible Storage.

MinIO

MinIO is a popular tool for running object storage natively inside Kubernetes clusters, by exposing data through standard APIs to enable containerized application to store, retrieve, and manage unstructured data. MinIO designed to run natively in Kubernetes, and allows you to bring-your-own S3 compatible storage or use your device’s local storage for a self-hosted solution. MinIO is flexible enough for individual developers to experiment with, but its power comes from its scalability, with 77% of Fortune 500 companies using MinIO in their cloud native workloads.

Velero

Rapidly creating and deleting infrastructure, and being able to quickly rebuild and recover are core tenets of Kubernetes. Velero makes it incredibly easy to back up Kubernetes clusters to your preferred object storage service. Run one-off backups as needed with one simple command, or set up a schedule to make sure your clusters are backed up consistently.

Read more about Kubernetes cluster security and backup strategy.

Rook

Rook is a storage orchestrator for Kubernetes that manages distributed storage systems (including Ceph and Cassandra) as native Kubernetes resources. Though Rook’s functionality doesn’t directly extend to S3 compatible object storage like Backblaze B2, you can mirror the data to B2 or set up your preferred object storage service as a backup destination. 

Container Object Storage Interface (COSI) (Currently available in Alpha)

The COSI project is a set of abstractions currently available in Alpha that aims to provide Kubernetes with the ability to request and provision object storage buckets from multiple cloud vendors, similar to how file/block storage is abstracted with the CSI driver. Since each cloud provider builds out object storage differently, COSI intends to provide a unified set of protocols so Kubernetes can be inclusive to all object storage vendors, and adhere to the Kubernetes portability tenet.

Learn more about these tools, see a demo of how to attach a Backblaze B2 bucket via the mountpoint for Amazon S3 CSI driver, and get some initial key takeaways from KubeCon North America during our upcoming webinar, The State of K8s + S3 Compatible Storage. Register to watch live on November 20, 2025 and get access to an on-demand recording.

The post 5 Tools to Integrate Object Storage and Kubernetes appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Post Syndicated from Yev original https://www.backblaze.com/blog/the-hidden-cost-of-cloud-storage-what-400-it-leaders-wish-they-knew-sooner/

Cloud storage was supposed to simplify infrastructure. Instead, it’s become one of the most unpredictable—and expensive—line items in IT budgets.

A new Dimensional Research report, commissioned by Backblaze, reveals that 95% of organizations experience unexpected cloud storage charges—costs that disrupt budgets, slow innovation, and limit flexibility.

The 2025 study surveyed more than 400 IT decision makers responsible for managing at least 250TB of data in the public cloud. The findings make one thing clear: as AI, analytics, and data-intensive workloads expand, hidden costs and limited interoperability are forcing companies to rethink their cloud strategies.

The problem: Hidden fees are everywhere

According to the research, nearly every organization surveyed has been hit by surprise charges like retrieval, egress, or PUT fees.

• 95% of respondents reported unexpected costs for cloud storage usage.
• Larger organizations—those with more than 5PB of data—were even more likely to experience frequent charges.

These hidden costs have become such a burden that 85% of companies are taking steps to manage them. The top tactics include:

• Reducing the size of datasets stored in the cloud (56%)
• Shortening storage duration policies (45%)
• Cutting spending elsewhere in the tech stack (40%)

In short: IT teams are making trade-offs to avoid surprise costs—trade-offs that can limit innovation and reduce the value of their data

Egress costs are locking companies in

One of the most striking findings: 

55% of respondents said that the cost of egressing and moving data is the biggest barrier to switching cloud storage providers.

That means many organizations feel trapped in their current solutions—not because the technology is best-in-class, but because moving their data would be too expensive.

This dynamic creates what’s often called a “walled garden” effect—where providers profit from data lock-in rather than delivering value through performance or innovation.

The result? Slower cloud adoption, limited agility, and higher total cost of ownership for IT teams trying to scale modern workloads.

Flexibility and interoperability are the new imperatives

If cost surprises weren’t enough, nearly all respondents (99%) said that limited flexibility and lack of interoperability are impacting their ability to deliver and scale.

In other words: even when data is stored safely, it’s often stuck—difficult to move, integrate, or use across tools and platforms.

This friction hits hardest at large enterprises and data-heavy organizations that depend on cross-cloud workflows, hybrid architectures, or AI pipelines that require moving large volumes of data frequently.

A turning point for cloud storage strategy

With 62% of respondents preferring to select best of breed providers vs. one-stop-shops, these findings highlight a growing shift:

• IT teams are no longer choosing cloud providers solely based on performance or ecosystem.
• They’re prioritizing predictability, transparency, and interoperability—the ability to move and use data freely, without hidden penalties.

Backblaze has long championed this model with open cloud storage that puts customers—not pricing structures—in control. Our egress fee transparency, S3 compatible APIs, and simple pricing are designed to eliminate the pain points identified in this report.As one respondent put it: “We need a cloud partner that helps us use our data, not pay to move it.”

What’s next: Join the conversation

The full report—The Hidden Cost of Cloud Object Storage—is now available for download. Inside, you’ll find all the data, charts, and insights from 400+ IT leaders across industries and company sizes.

And, to dive deeper into the findings, join us for an upcoming live webinar with experts from Dimensional Research and Backblaze. We’ll unpack the key trends, share real-world stories from IT leaders, and discuss how to build a more transparent, flexible cloud strategy.

About the research

The survey, conducted by Dimensional Research in May–June 2025, included responses from 403 qualified technology stakeholders responsible for cloud storage strategy and budgets. All participants represented companies with over 250TB of data stored in the public cloud.

The post The Hidden Cost of Cloud Storage: What 400+ IT Leaders Wish They Knew Sooner appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/the-reliability-edge-sres-have-been-waiting-for/

Site reliability engineers (SREs) are measured by one thing above all: keeping systems available when it matters most. They’re the ones getting calls at midnight, managing the war room during outages, and preventing small hiccups from snowballing into customer-facing failures.

But storage from major cloud providers often makes their job harder. Tiering delays stretch out recovery times. Replication gaps create blind spots across regions. Complex policy chains flood monitoring systems with noise. Instead of protecting reliability, general-purpose storage often undermines it.

What SREs need is a storage layer that works with them, not against them—one that delivers durability without complexity, speed without cold-tier delays, and clarity without policy sprawl.

A specialized, always-hot storage foundation provides exactly that.

This is the final post in our three-part series on how specialized storage helps every member of a cloud-native team. (See articles one and two to get the full story.) This time, we’re zeroing in on the reliability engineers who keep customer-facing systems humming behind the scenes.

Reliability starts with storage

For SREs, storage is the backbone of availability and recovery. When it falters, the blast radius spreads fast. Even a minor failure can ripple outward and amplify the impact of every incident.

In the sections below, we’ll look at how those ripple effects play out in real-world scenarios, and how specialized, always-hot storage helps SREs contain failures, recover faster, and quiet the noise that makes reliability so hard to sustain.

Contain the blast radius

SREs spend much of their time running “what-if” drills. What if a drive fails? What if a region goes down? What if replication lags behind?

With general-purpose cloud storage, those “what-ifs” become real risks:

• Tiering delays: Infrequently accessed data is automatically pushed into colder, slower tiers. During an incident, archived data such as logs or snapshots must be restored before it’s usable. This slows recovery when seconds count.
• Replication gaps: Replication isn’t always immediate or consistent across regions. When writes lag or copies fall out of sync, recovery data can be stale or incomplete, leaving teams guessing at the true state of their systems.
• Policy complexity: Layers of identity and access management (IAM), lifecycle, and routing policies often overlap in unpredictable ways. A single misconfiguration—like archiving active data or blocking a needed API—can cascade through dependent services, turning a minor error into a wider outage.

Each layer meant to increase flexibility instead adds fragility.

Specialized storage changes that dynamic. Designed for worry-free durability and built to eliminate single points of failure, it distributes data across independent systems so localized issues don’t cascade. Even if hardware fails or a region experiences disruption, data remains accessible and recovery stays predictable. For SREs, that means fewer nightmare scenarios to model, fewer “what-ifs” in runbooks, and faster, more confident recovery.

Cut mean time to recovery (MTTR), protect SLAs

When an incident hits, the SLA clock starts ticking. Every minute spent waiting on logs, snapshots, or configs adds pressure from customers and leadership alike.

But in tiered storage systems, those critical assets are often parked in colder, low-cost tiers meant for archival access rather than fast recovery. Pulling them back can take hours or even days before triage can begin. That latency bloats MTTR and turns manageable events into prolonged outages with real customer impact.

Specialized storage eliminates these bottlenecks. Always-hot data and millisecond reads give SREs immediate visibility into logs, snapshots, and configs, so evidence is available the moment an incident begins. Instead of stalling while waiting on a restore job, teams can dive directly into diagnosis and resolution. The results are faster MTTR, steadier SLA performance, and fewer fire drills turning into headline outages.

Reduce alert fatigue

Ask any SRE what wears them down and the answer comes quickly: false alarms and 3 a.m. wake-ups. The incident itself may be rare, but the noise leading up to it is relentless.

In big-cloud environments, complexity breeds that noise: 

• Lifecycle policies silently archive data until a request fails
• IAM rules misalign with pipeline needs
• Tier transitions or throttling events masquerade as outages in monitoring dashboards. 

Each quirk becomes another alert, another call, another night interrupted. Over time, the noise blends with the signal, and teams start second-guessing what’s real. Alert fatigue sets in. Engineers tune out notifications or delay responses, not from neglect but from exhaustion. The result is a slower reaction when a real outage hits, which is exactly the scenario the alerts were meant to prevent.

Specialized storage dials down the chaos. A single-tier design with clear access controls strips away layers of risk, keeping alerts meaningful and edge cases rare. Instead of burning cycles firefighting brittle rules, SREs can focus on resilience engineering and prevent outages in the first place.

Rethink storage, strengthen reliability

The SRE role is already demanding. Storage shouldn’t add to the burden. An always-hot storage layer gives teams the durability, speed, and simplicity they need to keep systems reliable without extra toil.

Backblaze B2 was built with SREs in mind:

• Architected for 11 nine’s of durability
• Millisecond reads that slash MTTR and protect SLAs.
• Simplified architecture that cuts noise and pager fatigue.

You don’t need to rebuild your stack to get these benefits. Just swap the endpoint and redeploy. With Backblaze B2, storage stops undermining reliability and starts strengthening it.

Tired of midnight pages for preventable storage issues? There’s a better way. Explore how Backblaze B2 fits into your reliability workflows, and how much calmer on-call life feels when storage simply works.

The post The Reliability Edge SREs Have Been Waiting For appeared first on Backblaze Blog | Cloud Storage & Cloud Backup