At 11, Björn Kolbeck met the machine that would organize his life. It was his first computer, and the ambition arrived quickly: he wanted to become a programmer. Decades later, when a podcast host asked about life outside technology, Kolbeck answered with a joke that barely sounded like one: “Is there anything outside of tech?” The line is useful because it catches both his dry humor and the unusual continuity of his career. He did not wander into infrastructure. He kept following the same fascination until a childhood hobby became research, then a job at Google, then a company.
The company is Quobyte, founded in 2013 with Felix Hupfeld. It sells software for storing and moving the huge collections of files and objects used in high-performance computing, enterprise systems, and artificial intelligence. The category can sound abstract. Its consequences are concrete. When data arrives too slowly, costly processors wait. When a disk or server fails badly, work stops. When expansion demands a new appliance and a specialist crew, infrastructure becomes an organizational constraint as much as a technical one.
Kolbeck’s career is an extended argument that these problems should be absorbed by software. The interesting part is not simply that Quobyte aims to run at scale. Plenty of infrastructure companies promise scale. His recurring concern is who has to operate that scale, what happens when ordinary hardware breaks, and whether growth requires the company using it to become a storage company too.
Failure as a field of study
Before there was a startup, there was a European research effort with the expansive goal of building a distributed version of Linux. Kolbeck entered it during his doctoral work and met Hupfeld there. Their responsibility centered on data management. That piece of the larger system became interesting enough to develop an identity of its own: XtreemFS, an open-source distributed file system designed for clusters, grids, and cloud environments.
At the Zuse Institute Berlin, Kolbeck became XtreemFS’s lead developer from 2006 through 2011. The work produced more than software. He co-authored papers on object-based file-system architecture, lease negotiation using Paxos, backup consistency, and replication across wide-area networks. His doctorate at Humboldt University of Berlin, completed in 2012, was titled “A fault-tolerant and scalable protocol for replication in distributed file systems.” Failure was not a late concern attached to a product roadmap. It was the subject.
Distributed systems ask designers to accept an uncomfortable premise: the parts can be individually alive while the whole still behaves strangely. Networks delay messages. Machines disagree about time. A component disappears halfway through a task. Kolbeck’s later shorthand for the posture is “never trust the infrastructure.” It sounds severe. In practice, it is liberating. Once failure is an input rather than a surprise, the architecture can stop demanding perfect equipment.
“Never trust the infrastructure.”Björn Kolbeck’s design principle
The small-team clue at Google
Kolbeck moved from research into Google in 2011, serving as tech lead for the Hotel Finder project until 2013. The product was not his final destination. The operating environment was. He and Hupfeld saw surprisingly small teams run storage infrastructure supporting a company of enormous scale. The observation reframed the opportunity. Hyperscale was not only a matter of more machines or more bytes. It was a ratio: infrastructure per operator.
This is the detail worth stealing from the founding story. Great businesses can hide inside something an exceptional organization has made look ordinary. Kolbeck and Hupfeld did not merely admire Google’s size. They noticed the headcount required to keep a foundational system working, then connected that observation to years spent building XtreemFS.
They founded Quobyte in 2013 and reunited with colleagues from the XtreemFS period. The team did not simply package the research project. It wrote a new system from scratch, carrying forward lessons about replication and distributed storage while expanding the feature set for commercial use. The product unified file and object access and ran on standard servers. The business proposition followed the technical choice: customers could add capacity and performance without buying a fixed appliance for every step.
Kolbeck often explains the design through operations rather than computer science. A cluster should keep going when a drive, server, rack, or site fails. Updates should not demand a maintenance window. Policy should decide where data sits. A small team with ordinary Linux knowledge should be able to operate the result. Each point translates architecture into labor, scheduling, and capital.
Scale is not merely how much a system can hold. For Kolbeck, it is also how little the operating team must grow while capacity, traffic, and failure opportunities multiply.
The engineer learns to sell
Deep technical founders eventually meet a second system: the market. Kolbeck has spoken about moving from technical work into sales and marketing, a transition that required him to spend more time with customers and explain the company’s choices in their language. Storage buyers do not purchase a replication protocol. They purchase fewer interruptions, less manual work, freedom from a hardware list, or better use of machines already paid for.
That translation now shapes his public vocabulary. Commodity hardware is about avoiding expensive lock-in. Automatic placement is about reducing administration. Linear performance is about adding resources without redesigning the whole environment. Hybrid deployment is about moving work without rebuilding its storage conventions. The technical integrity remains, but the unit of explanation shifts from mechanism to consequence.
The evolution also shows in Quobyte’s releases. In 2024, its File Query Engine made file-system metadata searchable in parallel without asking administrators to maintain a separate database. Quobyte 4 arrived in April 2025 with native ARM support, cloud object integration, broader observability, S3 governance tools, and single sign-on. Kolbeck described the goal plainly: let AI engineers and researchers focus on their work rather than the infrastructure beneath it.
That year, Quobyte published results from an internally run MLPerf Storage 3D U-Net test. Kolbeck called it the workload that “really exercises and tortures the storage system.” The numbers were not an official MLCommons submission, an important boundary, but the test clarified his economic pitch. A storage stack does not create value by winning an isolated race. It creates value when the GPUs on the other side remain supplied with data using fewer servers, less power, and less floor space.
“In the end, the GPU must be busy at all times.”Björn Kolbeck on AI infrastructure, 2026
Training once, remembering often
By mid-2026, Kolbeck said the customer conversation had swung from training and fine-tuning toward inference. The shift sounds like a software detail until an agent carries a long conversation, loads documents, and accumulates context that must persist. That context may grow far beyond GPU memory. It moves to host memory, local storage, and eventually a durable system. When the user returns, it has to move back quickly enough that expensive processors do not wait.
Quobyte’s answer is GPU-converged storage: run the storage software on the GPU servers and use their attached drives and high-speed back-end network as a shared pool. Kolbeck originally discussed the approach in terms of cost, energy, and scarce hardware. The inference workload added another use. Distributed context can be pulled across the broad network already linking the GPU nodes, easing the narrower front-end connection.
The technical fashion has changed several times across Kolbeck’s career: grid computing, cloud, containers, machine learning, training clusters, and now agentic inference. His underlying position has moved less. Decouple the system from specialized boxes. Expect physical components to fail. Spread work across ordinary machines. Automate repair and placement. Keep the people using the infrastructure focused on what they meant to do with it.
A life with the hobby left in
The risk in telling a career this consistent is making the person sound like a protocol. Kolbeck offers a few counterweights. He is a father of two. He enjoys the gym and travel, though startup life made the latter feel like a luxury. He has singled out Costa Rica for its people and landscape. Then there is that answer about whether anything exists outside technology. It works because it is both teasing and honest.
His story is not about a sudden founder revelation. It is about accumulated proximity. A computer at 11. A research assignment that introduced a co-founder. An open-source system that exposed the hard edges of distributed data. A doctorate that formalized the failure problem. A Google role that revealed an operating model. Quobyte emerged when those pieces stopped looking separate.
Thirteen years into the company, Kolbeck is still applying the same thought to a new bottleneck. AI has made compute visible and storage consequential. His wager is that infrastructure earns its place by becoming less theatrical: fewer emergency interventions, fewer special boxes, fewer reasons for a scientist or engineer to learn the storage system’s private anxieties. The machinery will fail. If the design is good, the day can continue.