Bazel Is Not For You | Byte Bard Software
Bazel Is Not For You<br>June 20, 2026I know the title sounds like clickbait, but hear me out.<br>I make a living helping people with their Bazel builds. My ability to put food on the table is directly correlated with more people using Bazel. I’ve staked my career in the fact that people need great builds, and that Bazel is a great way to get there.<br>So please believe that I don’t say this lightly: Most organizations shouldn’t be using Bazel.<br>Here’s what I’ve observed, after almost a decade knee-deep in the hermeticity trenches.<br>Point 1: Never Start With Bazel<br>Please, please don’t start a new project with Bazel. Unless you’re absolutely sure that your organization is going to grow to hundreds of engineers, just stick to whatever Hello World your language of choice gives you.<br>Let’s really think about it. When you’re starting out in a project, you have Big Questions to think about: What am I building? Is this even worth building? Should I be building this? Does anyone want this?<br>Compared to those, “should I strive for hermetic builds to gain 50% faster CI?” shouldn’t even qualify as a nagging thought.<br>Any extra effort you spend on finding the right ruleset, or wiring toolchains together, or anything that is not absolutely required to get the thing running is time you’re taking away from the things that will make your project succeed.<br>Just pick whatever build tool is in vogue for the language of your choosing, and move on.<br>Until you get to ~100k lines of code, you’re not going to notice the difference in build performance anyway.<br>The only exception I’ve seen, the only case where I would recommend starting with Bazel, is any time you really care about which compiler you’re using.<br>Mostly, this applies to embedded systems, and systems that need to cross-compile to target a specific, esoteric, and custom system.<br>In these cases, you’re already opting into build pain, so it makes sense to pick a tool that helps you surface, reason about, and manage that pain, like Bazel.<br>But if you’re building a web service, even in Rust, please just use Cargo.<br>If the project gets big enough, we can talk about migrating to Bazel.<br>But even then…<br>You Need At Least 6 People In Your Bazel Team<br>After working with dozens of teams and organizations, and gathering hundreds of second-hand data points, I observed the following: The teams that struggled with Bazel the most were the smallest ones. This appears pretty obvious, until you couple it with the fact that this held true, regardless of the overall size of the org they were serving .<br>So, a team of 2-4 people struggled to serve 20 engineers just as much as 100, whereas I’ve seen build teams of 8-10 serve companies of 1000 engineers comfortably. To put it in other words: Bazel’s returns on investment are non-linear. Or even better, to put it visually:
This seems to indicate that, unless you’re ready to dedicate a minimum of 5-6 people exclusively to becoming Bazel experts, you’re going to have a bad time , and should probably stick to native tooling.<br>Which is my main point: Most organizations aren’t ready to have 6 full-time Bazel engineers, so they just shouldn’t do it.<br>Wait, Why Does This Happen?<br>To be honest, I don’t know. I have enough data to say that it is true, but I only have guesses as to why.<br>Anecdotally, it seems to me that:<br>There is always a minimum of work involved in keeping the Bazel lights on: You need to make sure the rulesets you depend on are up to date (and contribute fixes if not), you need to keep up with Bazel versions, figure out what the heck to do with protobuf, that sort of thing. This is a constant of work that (1) will probably be unique to your organization, and (2) doesn’t really depend on the size of the org.<br>You may find yourself maintaining infrastructure. Bazel’s promise is that it’s so hermetic you can have an artifact cache in the cloud to avoid 80% of your build actions. Well, since you did all the work to migrate, it stands to reason that you should stand up a cache to reap the benefits, right? Well, keeping a live service up is a non-trivial task. Suddenly, you have oncall rotations, and outages, and you need to procure capacity from whoever manages your clusters, etcetera. Build cache services are relatively easy to maintain, but even in the best of days they take a non-trivial amount of overhead1.<br>You get more customer support requests: Most engineers out there are very comfortable with native tools, and have no idea Bazel exists. When something breaks in cargo, their first instinct is usually to Google it, and it’s likely they’ll find a solution. When something breaks in Bazel, even if they try to Google it, chances are they’ll end up just reaching out to your team.<br>So, yeah. Unfortunately, I’d recommend your team be...