More than two years ago, Snowflake’s Developer Productivity team migrated Snowflake to Bazel and RBE, running internally managed clusters across large Java and C++ codebases. The team involved comprised experienced Bazel engineers, including former members of the Google Bazel team.
At that stage, Snowflake had what many engineering organizations aspire to: a modern build infrastructure, backed by deep internal expertise, and full control over the platform.
As Snowflake scaled to over 2,000 engineers and a multi-million-line codebase, however, the operational requirements of maintaining and tuning their self-managed RBE toolchain grew along with the organization.
This meant allocating internal engineers to continuously manage cloud resources to ensure predictability, perform complex platform upgrades, and scale infrastructure as demand rose.
Snowflake did what strong engineering teams do. They tuned the system, applied more care to upgrades, and focused efforts on stability, cost consciousness, and performance.
But the effort came with a considerable opportunity cost: in order to keep moving fast, Snowflake needed to allocate up to 5 elite developer productivity specialists at a time focusing on infrastructure maintenance.
In the end, Snowflake’s leadership reframed the decision: since they knew they could run RBE themselves, the question became whether it was worth assigning talented engineers to operating a high-cost distributed system on the company’s critical path.
First, Snowflake moved to a managed service model, retaining the benefits of Bazel and remote execution while EngFlow absorbed the operational complexity of running the platform.
Second, EngFlow brought technical capabilities that directly addressed Snowflake’s pain points.
Managing remote caching at Snowflake’s scale is highly resource-intensive. EngFlow’s remote execution and cache architecture, featuring automatic spillover to Amazon S3, allowed Snowflake to meet optimal time-to-live (TTL) windows and reduce storage costs.
EngFlow also made previously difficult platform capabilities straightforward. For example, it had been impractical to offer engineering teams a choice of execution base images because each additional image expanded the platform’s operational surface. With EngFlow, adding an image became a mere configuration change.
Snowflake now runs 17 million builds and 290 million actions per week on EngFlow.
EngFlow’s autoscaling, scheduling, cache architecture, and data-transfer efficiency led to a nearly 50% reduction in AWS costs for cloud infrastructure compared with the prior self-managed setup, while build performance improved.
The staffing model changed just as dramatically.
Before EngFlow, Snowflake needed as many as five engineers at a time supporting RBE. After the migration, the number dropped to roughly half an engineer, with EngFlow managing the operational complexity.
This new stability also unlocked progress. Onboarding new workloads stopped being an event that could delay production deployments.
