Backblaze, Inc. (BLZE) Earnings Call Transcript
October 8, 2026
Earnings Call Speaker Segments
Hi everyone. Welcome back to our quarterly drive stats report. My name is Stephanie Doyle, and I am the Senior Manager of Market Intelligence and keeper of stats. And joining me today is David Johnson, who's going to walk through this quarter's drive stats report as well as we're going to get into a discussion of some of the drive technologies on the rise in existence that are bringing the industry to what it is today and will be tomorrow. So David, do you want to introduce yourself?
Yes. Thanks, Stephanie. It's a pleasure to be here today. I've followed drive stats for a very, very long time. I've been in tech for a while now, so it's just like a backbone to me. I think we're in our 13th year of drive stats, I believe. So we're still kicking strong.
Yes, it's 13-plus. We started tracking the data and then we did our first report with a little bit of a gap. So if you look at the full data set I think we're not quite at 14, but if you look at where the reports started, we're at 13 solidly. So it's a data set that only keeps on growing and definitely keeps on giving, so always fun to do these reports. A little housekeeping for folks who have joined us before or -- who are joining us for the first time today, webinar is being recorded. Of course, please ask questions. And there will be attachments that we add at the end, including the slide deck from today. You can always catch the blog and all that other good stuff on our website. We'll have links to those at the end of the slide deck as well. So this is the project, of course, since 2013, David, you and I just talked about how long it's been around. We've collected, curated and published raw device metrics including -- and then transformed that into annualized failure rates and related statistics from hard disk drives and solid-state drives in our data centers. Each quarter, we publish this open-source data set, which can be downloaded on the Drive Stats page, check that out at backblaze.com/drivestats. And we do try to keep up an iceberg version of this data set on our GitHub, so you can find that as well linked. This is a top line snapshot. So I always find interesting that drive count up and only going up, as I say. Drive days, of course, is how many days, all of our drives had to date. And then drive failures is just the raw count of numbers there. Drive population by manufacturer. Of course, we had WD purchase HGST. So from that perspective, we're at about 1/3, 1/3, 1/3 in drive manufacturers, which is always helpful when we're looking at numbers. Certainly, not one to play favorites. We have a lot of -- there's a lot of great drives out there, and so we like to have everything nice and balanced.
Yes. And that's the benefit of our platform. It allows us to be able to use a good amount of these drives from different manufacturers and be able to have very efficient software and infrastructure that can help run it all.
Software layer on top of commodity hard drive, driving all the value there, of course. So this is the Q2 2026 data, as always, incredibly difficult to read the full table. We always encourage you to dig in on the blog itself. But you can see here at the bottom that our annualized failure rate for this quarter was 1.73%, and this is a market rise in quarterly AFRs. Why? We did -- first thing that I always do when I see a quarterly rise is to run an outlier test. But before we get there, let's talk about drives that had zero failures. So clean sweep from the Seagate this month, we had zero failures on the 8-terabyte, 12-terabyte and 14-terabyte Seagates. These models identified here and one on the 16-terabyte Seagate. And we also saw the retirement of some very old drives in our system, so that would be the 4-terabyte HGST, 8-terabyte HGST as well, clocking in at 9 and 8 years old. And then a little bit of a curiosity here. No new drive models. We certainly had new deployments, but they were all of existing drive models. I flagged last quarter that it's actually quite rare for us to not have a new drive model, I think, in the last 3 years or something like that. It's only happened once. So to get two quarters in a row, feels a bit odd but it is nothing to say there. It's really just so we're getting the same models deployed in our system at about the same volume.
Do you think that speaks to just efficiency of where we're at nowadays? I mean, it could be a number of things, but it seems like it's a good thing that we're sticking with the same models.
I think the biggest thing is that it's not that our growth of platform hasn't slowed down. I think it's the biggest reason I really want to talk about it, it's just that when you're deploying vaults as much as possible, you want them to be really identical. So if we can get our hands on the same models and those models are functioning well within our system, why wouldn't we continue with the drives that are already qualified? Of course, there's like work on multiple ends of the spectrum there, qualifying drives. It also means you have more capacity to swap in and out if you have failures, all that good stuff. So in terms of creating a happy system, it certainly helps to have similar models, especially if they're functioning well. So let's -- I think we did not pull our review of the outliers, but you can certainly go check out the blog for that. But let's go back to the table for just a minute, and you can see here that there's a couple of models. This one up here is 7.63%. And then you've got 8.26% here. And a third with -- excuse me, I'm losing it here, 9.33% on the Seagate 10-terabyte. So those three, from a statistical standpoint, outliers. And they did have very normal reasons for potentially reaching this high failure rate. So in one case, you -- or actually, in two cases, you had drives that were quite old, so more than 7 years. And then in two other cases, so that would include one of those quite old drives, you had drives with a very low drive count. So that means that if you get a raw number of drive failures like looking at the Seagate 14-terabyte with the 8.26% failure rate, it's really only 25 failures, but when you only have 1,200 drives that makes more of a difference in your AFR at the end of the day. So two of them that were quite old, two of them that had very low drive counts. And for that, those are all pretty normal indicators that they're actually already being cycled out of our system, so not a huge amount of worry even though the AFR did seem high on the surface. Let's talk lifetime data. So again, you've got the full table here. The AFR down here at 1.41%. That's like very consistent to actually the AFR for the lifetime data for understandable reasons, tends to not fluctuate as much as the quarterly. So I think it's usually 1.39%, 1.40%, 1.41%. I feel a little bit like a broken record when we review the data on this one, which once again speaks to the fact that we are a managed system. Somebody is trying to make sure we're within good and healthy ranges there.
Yes, it's always a good thing when things kind of stay the same. It means things are working, nothing's going bad.
Yes. We want consistency, we want a low failure rate, we've got them, right? And there's always going to be some variability things you can't account for. But certainly, there's -- over time, it tends to come out in the wash. Four models didn't make the cut to the lifetime table. This means that they've dropped below your total drive count. Interestingly, several of these were also our zero failures, David. Yes. I always find that quite interesting because we've said for a long time, drives are getting better, lasting longer. And those aren't -- you still have to migrate things out, but I find it's always a question from our readership where it's like, why are you retiring the drive if it's still going so well. It's like, well, you have to do risk mitigation at a certain point. But if you're looking for longevity of drives, readership, sometimes these things happen, right, which is pretty cool.
Yes. It's very interesting to kind of look at all of the data that I've seen over the years where kind of see this trend moving where we're cutting out some smaller drives, putting in those larger drives and seeing how the failure rates track against those. And I know like just doing some math off the top of my head, I think it's like nearly 1/4 of our fleet now is approaching the 20-terabyte mark in drives. So I'm really interested to see that same kind of bathtub curve almost as we get into the [ larger ] drives.
I think it's important to note, and we did get this question on, I believe, our Reddit platform, like do we see inherently a larger failure rate for larger, smaller drives. I think the mix of capacity within our system really is indicative of industry trends over preference, although there is a little bit of a preference to maximize your -- how much density you have per rack. So if you put 20 6-terabyte drives into one server, you can -- it doesn't store as much as 20 20-terabyte drives per server, of course, right? But we haven't really seen higher failure rates in the population as correlated to age, and that's something that we did most -- that analysis we did most recently in 2025, sort of separated out our drives by introduction point as well. But I will say that it's a bit early to make that call, right, because the 20-terabyte drives are still quite young, and I think our oldest one in the system is maybe coming up on 2 years. So certainly something to pay attention to over time, especially as we talk about new storage technologies, right? So I brought this forward in our drive stats report this time around because I think that it's probably one of the biggest questions I've been getting at my last couple of speaking engagements. So let's just start with CMR, I'd say, and then talk SMR. So David, do you want to walk people through what CMR is and what it would mean to like a consumer in terms of what a hard drive is itself?
Yes. I mean CMR, it's kind of what we've been running with for a while now. I don't know exactly know how long we've been running with them, but it's kind of been the standard we've been with. I mean, they're...
Kind of your normal...
Yes, it's your normal. They're predictable, they're proven performance. It kind of led us to a lot of good innovations over time. But as we're kind of getting to the point where we're seeing more performance workloads with sequential things. We start to see some of the limitations of CMR drives. And I think that's where the industry is now moving into the SMR side of things, which starts to solve some of those issues and also give us some greater capacity as we move forward, too.
Yes. I mean I think my perspective is that the single biggest driver to SMR is what's been driving the drive industry for a long time, how do you store more data in the same physical drive, right? We've seen adding more platters. We've seen magnetically assisted reads and writes, all that other good stuff. And shingled magnetic recording is quite interesting, I think, because it actually uses your platter zones in a different way. and we have some handy-dandy visuals to make this clear because I think that it's a bit complex if you don't understand what's happening with the -- on the physical level. So the first thing is the reason this is possible at all, is because the width of the head that writes your data is narrower than the width of the data that reads -- or the width of the head that reads your data. And we -- this is actually true in both CMR and SMR. So what you're looking at here is actually a CMR drive, how it would read and write the data, and these bands would sit side by side like traditionally, right, your widest, which means that you can write simultaneously and all other sorts of good stuff. In an SMR drive, what you actually do is you overlap the tracks so that you can create more density, and you're write-with is going to allow you to write like this, whereas you're read-with is going to be kind of sitting inside that or overlapping that. So if you were to look at these side by side, you can really see the difference here. And this lets you make more use of this -- the existing space. It does also have implications for how you can read and write? The biggest one is that you can't sequentially write things because you will have overlap, right? And so there's things that make it -- within a data center, things that you have to think about in terms of how you interpret it. There are also firmware implications there. So you have drive assisted -- or driveware SMR or you have firmware -- like firmware assisted -- let me go ahead and look at my notes because I feel like I'm butchering this now. But you have drive managed SMR, host-managed SMR or host-aware SMR. And that's just who makes the decision where, is the drive doing it, is the host doing it, or is it a combination of the two? So all these things have implications for how we provision drives. It also let you get more data onto a single drive, which is very exciting, right? That's the same way we're talking about what we can do with bigger drives in a single server. Now we can do this in a single drive. We personally do not yet have SMR drives rolled out. But I think the biggest thing what we're hearing from all the drive manufacturers is that this is where the industry is going. So if CMR is our normal now, SMR is going to be everything in about like 18 months, 2 years, at least for enterprise. Is that what you're hearing too, David?
Yes. I think we're still a little ways out, but that feels like a long time, but trust me, it'll go quite very quickly.
Yes. So when you talk about why this matters. Number one, it matters because we're seeing drives get bigger and a lot of very interesting technology on the bottom of that. And number two, it matters because you have to sort of optimize your storage layer for the new way these things are working. So for Backblaze, that's kind of been our bread and butter this whole time. We're looking forward to it. You do have to interact with that both directly with the drive manufacturers and within your own system.
Stephanie, before we jump into HAMR, we had one question that popped up with the SMR drives. They were wondering, don't they usually have a massively increased rebuild time when they're used with a [indiscernible] drive?
They can, but there's things that reduce that. So when we're talking about provisioning, right, we're sort of looking at all the different ways that will matter. And I think this is a pretty astute question. I'm looking in the chat. I see Robert, you asked this, because when you're -- it's one of the biggest things that affects parity. So we know that our parity schema has had to shift as we have more large drives, right? Because as you talk about what -- when you think about what parity is, it's a formula. It is, in fact, just the time it takes to rebuild data as one of the parameters completely without any data loss. So if you think about how your shards have to be distributed, the larger your drive, the more likely your shards will end up too close to each other, so you actually have to increase and reduce your parity shards accordingly. Now if SMR takes longer to rebuild, that would also affect your parity schema. So when you talk about a single drive rebuild, again, we haven't gotten into provisioning these yet. So we're not -- we haven't thought about what it means for our testing purposes. There may be things you can do on the software layer. But one of the biggest things is when you're talking about a ratio coating, it actually has a built-in mechanism so that we can control for this on some level, right? We might change the way our parity schema works in sort of in our distributed file rebuilds. But that does also mean that when you're rebuilding a single like a vault or if you have a drive that goes out, you might have to account for that. Again, Robert, not something we have gotten into testing yet, so I couldn't give you real numbers on that. but certainly something our drive team will be on top of. So I throw in HAMR here, not necessarily because it's related to CMR, SMR. I know there was some confusion around that. But because a lot of times when you get into like the acronym soup of what is happening in drive technology, this one comes up to, they're like, well, but then what is HAMR if these are CMR and SMR? And HAMR, I find interesting because it's one of those -- I'm calling it a co-technology, but that's kind of not exactly perfect, but it's another piece of how we write to drives that significantly moved us forward on drive density. So whenever you're writing on a drive, you can see this north-south layer here. And your biggest issue is that if you haven't written things well enough, those bits can flip -- and when those bits flip, you have data corruption, right? So the first thing we did to help with this is heat fields or magnetically assisted writes. Those are two different ways you can create more durability. And HAMR itself is actually shoots a little laser straight down in there and gets a lot better write durability, which is very cool. And so it makes much more stable magnetic grades. What's even more interesting about this is that these are typically written onto a glass substrate versus aluminum. And you can do that because you can heat it up to a higher temperature, right? So they're already standard in like 2.5-inch drives and increasingly common in your 3.5-inchers. And so when people say, CMR versus SMR, it's not really a versus HAMR. It's like, and also there is HAMR. But if you look at, say, what is it the Mozaic drives out of Seagate, I believe all or almost all of those are glass substrate and HAMR drives. I may be speaking on the glass substrates specifically, but they're HAMR drives. That's what's getting them to those 40 terabytes and Western Digital is projected to get to 100 terabytes with HAMR technology as well. So I did some leaking out in the blog article, in case you want to see what drive manufacturers are talking about with that. But just know it's not an either/or, it's an and. I think that's helpful for folks to know.
And it's also just a great shorthand way of saying HAMR is pretty good, easy to remember.
I did go heavy on the puns this time around with like building, considering that hard drives are the building blocks of our data platform and all sorts of stuff. It was great.
Got to love the acronyms.
Get right in there. So I'm seeing one more question in the chat here, so Tushar, I hope I'm pronouncing your name correctly. Do we also track data for SSDs? What a spicy question that we get often. I will tell you, we have put out data on the SSDs in our system before. It is deeply imperfect because when you compare what our hard drives do versus what our SSDs do, they're completely different workloads. So we don't really have any data storing SSDs. We do have a layer of SSDs that are right through cash. So that would mean that they receive the input capture the data, tell you on the other end, hey, we've got your data because we do, and then they move that through to hard drive as in a queue, right? So it gives you better speed as a user, it gives us better ability to sort of control the file uploads I've considered restarting a report given that we do have some that are sort of data storing now. But if you compare even what the right through cash is doing versus what our boot drives and servers are doing, it's just not apples-to-apples. And given that the population is a lot smaller than our hard drive population as well, the fact that we have far fewer drive models getting hit with very different data workloads and in a sort of much less uniform environment. So we've held off always a possibility we'll bring it back especially as our platform expands, because I know people are hungry for real data on that front, and so am I. So we'll see what happens, no promises. It really, to me, it always depends on if we're giving the right context around the right data points and all that good stuff.
And if you're interested a little bit about how we use our right through cash, there's a lot of blog posts on our site around shard stash that go into depth about this. So if you're just a technical kind of person, those will be some great blogs for you to take a look at.
I'm seeing another question here from James. Do we normalize failure rate to drive size? Would you -- wouldn't you expect bigger drives to fail earlier or more often? What an assumption, James, and not in a bad way, I've heard it a couple of times. I think that the first thing to take into account, so when we talk about failure, we're not actually talking about failure to write, failure to read, failure to rebuild. We're talking about a true hardware failure here. And we go on record about what that means for us, and I think it's the Q3 2025 drive stats. But this is really want to drive fails and can't be rebuilt or can't be reset. Have we normalized drive rate to failure size. There's a couple of times we're taking slices to look at that. But one of the limitations is that we have deployed in waves over time, almost correlative to drive side. So if you look at early on, we were about terabytes. And then we had a period where 14 to 16 terabytes were quite popular for us. And now we're into the 20-plus like all of our -- almost all of our new deployments with the exception some 16-terabyte drives or 20-plus. So what that does is that it introduces a variable that we know has significance. So if you say older drives fail more often, which is true. And then you try to compare apples-to-apples as far as the 14s and the 16s to the 20s that it currently exists, that's not really fair. We have done a bathtub curve analysis to say when drives are failing over time, how often do they fail at year 0, year 1, year 2, year 3. And within that, we took some slices of the 14 to 16s versus the 20s to 25s. So like at year 2, did the 20 fail more often than the 14 to 16. But at that time, we had not a ton of -- we had maybe four or five models total of 20-plus terabyte drives in our system. So we'll likely refresh that analysis again. But the short answer is that you got to sort of correct for a couple of variables before we can make the question that you're asking very visible. And if you ever want to do that analysis yourself, I will happily remind you that the full logline data set is published quarterly so that you could take that and run it if you want to, instead of waiting for our analysis that comes out whenever we can get around to it basically. All right. Let's see if there's any other questions here, anything we didn't answer.
I think we had another question come in by Tushar. He left a reply that he's especially interested in the right heavy workloads like the right through cash. And he was asking would it be possible for us to share how we manage them at scale. That's a lot of what the blog posts talk about that we have, but Stephanie, what other thoughts do you have?
Yes, we haven't really taken a slice at like -- so especially interested in the write-heavy workload like you're write-heavy cache. So we don't -- when things get uploaded to our system, we don't like categorize by how many operations on which drives are happening here, right? We don't have if you were in like a hyperscaler environment. Obviously, they have different tiers about access and all these other things, which means that you can get a different lens on that potentially or a different way to attack that. And we don't have that data correlated with our drives yet. And even with great heavy work we can't even say necessarily that the right through cash is accepting more right heavy workloads, I would say. The biggest thing it captures really is small files instead of right heavy workloads. So as far as access patterns go, I don't think that you have a clear answer there. If we wanted to talk about how that works. Really, what we have -- where we have been talking about that is in the Performance stat series, where we do an external -- it's an external benchmarking report based on work standards, such as MinIO's published, open-source benchmarking of object storage. And there, we talk about -- we separate things by file size, thread count and run throughput standard throughput testing as well as upload download averages. And I think you can get a better perspective on our platform there. It's just not correlated to drive failure rates. The other place you might want to look is that our network stats plug. It's imperfect as far as getting down to, I think, to your specific question, but it does have a perspective on how things are moving into and out of our system. So with the triangulation of the three reports, you get a couple of different stuff, things in there. And Noriko, I'm so sorry, I didn't see your question. Also hello and I owe you an e-mail. So I'll be getting back to you shortly. We have to plan for SMR drive deployment and HAMR drive deployment. I don't know where those sit on the road map. I don't want to speak for engineering. But I think it is fair to say especially with what we just talked about, about how product road maps are going to drive manufacturers that near future is in the cards depending on how you define near future not tomorrow within 5 years, which I don't know if that counts.
It's a good way to put it.
And as far as system changes, that's something that we don't have the scope on yet. But what I wanted to lay the groundwork for in this report and the reason we're talking about it now is that I think that we did a similar thing when we saw our drive capacity start to raise. We said, "Hey, these things are coming down the pipe like let's make sure that we have a full understanding of what the effects might be and then let's track against it and see what actually happens." And I'm very excited to do that. with emerging drive technologies to SMR HAMR as well. And I think what we'll do is the same thing we've always done, which is say, "Hey, guess what, these drives are here now. pay attention to these models if you're interested in how those are functioning." All right. I'm not seeing any more questions in the chat. Anything you can think of David, any final thoughts on your side?
No. I think this has been a wonderful look at kind of a very concise quarter. Things were consistent. We're seeing some new technologies come into play. And I think it just makes me more excited to see where we go next with our reporting because I want to see the day that we get to 100 terabyte drives and 120 terabyte drives and we'll be around to kind of report on how those are functioning when we get there.
David, I love it. We're going to be -- I feel like we just made the whole audience say when.
Yes. Yes, exactly. Won't be tomorrow, but it will be some time.
It is a very exciting time to be seeing all the leaps forward in technology in the hard drive manufacturing space. So always fun to have a front row seat. And just to wrap it all up, you've got your resources slide here, folks, if you need anything. By the way, drivestats@backblaze is a monitored inbox, but you can also reach out directly to me if you'd like, I'm sdoyle@backblaze. And then we've got we just took some questions, and we'll upload everything else to this webinar page after we're through here. So thanks, everybody, for joining. We always appreciate it. We'll see you on the next one.
Thank you.
Read the full transcript via the API
You're viewing the first half of this call. Get the complete Backblaze, Inc. transcript - plus 256,000+ transcripts from 12,000+ companies, speaker segments and full-text search - through the EarningsAPI REST API or hosted MCP server.
Get an API key View API docs →For developers and AI pipelines
Programmatic access to Backblaze, Inc. earnings transcripts and 256,000+ others is available through the
EarningsAPI REST API and the hosted MCP server.
Quarterly plans from $145 - full transcripts, speaker segments, full-text search,
and the /api/v1/transcripts/recent polling endpoint for ETL pipelines.