Clustrix, YC Founder Story

Company: Clustrix Founders: Paul Mikesell (CEO/Co-founder) & Sergei Tsarev (CTO/Co-founder) YC Batch: Winter 2006, one of YC's earliest cohorts Industry: Database Infrastructure / NewSQL Founded: November 2006 | Product Launch: 2010 (Appliance), 2012 (Software-only) Total Funding Raised: ~$72 Million (Sequoia Capital, USVP, ATA Ventures, Y Combinator) Exit: Acquired by MariaDB Corporation, September 20, 2018 Peak Transaction Volume: 25+ Trillion transactions/month

---

---

The One-Line Summary

A serial founder who already built and IPO'd one $2.5 billion company walked away from a comfortable exit, saw the exact same scaling problem destroying the next wave of the internet, and spent 12 years quietly building the database that the world's fastest-growing web companies would depend on, before handing it off to the open-source community.

---

Lens 1, The Before State

Who Were They Before YC?

Paul Mikesell is not the kind of founder most people picture when they think of a YC W06 application. He wasn't a dropout in a dorm room. He was a University of Washington computer science graduate who had already co-founded Isilon Systems in 2001, a distributed storage company that went public in 2006 and was ultimately acquired by EMC for $2.25 billion in 2010.

Before Isilon, Mikesell had spent years at RealNetworks, the company behind the early internet's audio and video streaming infrastructure. He understood at a bone-deep level what happened when data storage systems hit their limits under real production load.

Sergei Tsarev came from a different corner of the same world. He had spent years building a time-series database for AOL, one of the highest-traffic internet properties of the early 2000s. He understood exactly what relational databases looked like when millions of simultaneous users started hammering them at scale.

These were not two people discovering a problem for the first time. They were two engineers who had spent the better part of a decade watching the same wall get hit, again and again, by company after company, from the inside.

The Personal Pain They Were Living

While building Isilon, Mikesell watched a pattern repeat constantly across the internet landscape. Fast-growing companies would build on MySQL, the default choice for any startup in the mid-2000s. MySQL was free, well-documented, and easy to get started with. Until it wasn't.

The moment a company hit real scale, millions of users, billions of transactions, e-commerce checkout flows under peak load, MySQL would buckle. The standard engineering solution was sharding: manually splitting your database across multiple servers, rewriting your application logic to query across those splits, and essentially accepting that your engineering team would spend significant time managing database complexity instead of building product.

Sharding worked, in the same way that duct tape works. It was painful, error-prone, expensive to maintain, and required highly specialised engineers to implement. And every fast-growing company on the internet was being forced to do it.

Paul and Sergei had both watched this happen from the inside. Their question wasn't "is this a real problem?", they had lived it. Their question was: what would it look like to build a database that never required sharding in the first place?

Why They Were an Unusual YC Profile

YC in 2006 was not the global powerhouse it became. It was Paul Graham's early experiment in funding young, scrappy founders, often students, with small cheques and good advice. Mikesell and Tsarev were older, credentialed infrastructure engineers with enterprise backgrounds. They looked nothing like the typical YC archetype.

What made them fit anyway: their problem was deeply real, technically unsolved, and urgently needed by the exact community, internet startups, that YC was beginning to serve at scale. Paul Graham understood that the best technical co-founders could come from industry, not just academia or college dorms.

Key Insight for Aspiring Founders

Domain expertise from your day job is not a liability, it is a targeting system. Paul Mikesell didn't find the database scaling problem by reading papers. He found it by watching Isilon's customers suffer through it for years. Your most valuable startup idea is often the one hiding in plain sight at your current job.

---

Lens 2, The Idea Origin

How the Idea Was Actually Born

The Clustrix idea didn't arrive as an epiphany. It crystallised from frustration accumulated across years in production infrastructure environments.

At Isilon, Mikesell had solved distributed storage, the problem of making many machines act like one reliable storage system. The architecture was elegant: instead of one massive server that would eventually hit its limits, you had a cluster of commodity machines that scaled horizontally. Add a node, add capacity. It was a fundamentally different way of thinking about infrastructure.

The question he brought to Clustrix was: why doesn't the database work the same way?

Sergei Tsarev had reached the same place from a different direction. Building a time-series database for AOL's high-traffic systems, he had repeatedly bumped into the transaction bottleneck, the point at which a relational database simply couldn't process writes fast enough to keep up with user demand.

The two came together around a shared conviction: the internet was growing faster than the database technology underneath it could support. MySQL was not going to scale to where the web was going. NoSQL databases, MongoDB, Cassandra, offered scalability but sacrificed the ACID transaction guarantees that e-commerce, financial services, and any business handling real money absolutely required. There was a gap in the market large enough to drive a decade-long company through.

The First Ugly Version, And the Key Technical Bet

Mikesell and Tsarev made a decision early that defined everything: they would build the database entirely from scratch. Not a layer on top of MySQL. Not a wrapper. A completely new distributed database engine, built to be MySQL-compatible from the API layer, so existing applications could switch without rewriting their code.

This was an audacious technical bet. Building a new database from scratch is one of the hardest things in software engineering. It took Clustrix four years from founding (2006) to shipping a product (2010 appliance). Four years of building before a single customer used it in production.

The initial format was a hardware appliance, a physical box that companies would deploy in their data centres. This was not the obvious move for a software startup, but it made sense: the hardware appliance let Clustrix control the full stack, optimise performance precisely, and sell a predictable, testable product to enterprise customers who were not yet comfortable with cloud-native database deployments.

The Signal That It Was Working

The first public proof of concept came from Twoo, a social networking site run by Massive Media. Twoo had exploded to four million users in just six months, and their MySQL installation was visibly failing under the load. Sharding was the standard answer. Clustrix was the alternative.

When Twoo deployed Clustrix and their transaction throughput problems vanished without any application code changes, the case study wrote itself. A social network that had grown 4 million users in half a year was now able to scale its database as fast as it could acquire users. That was the proof Clustrix needed.

The Pattern This Follows

Clustrix fits the "pick the unsexy infrastructure problem that everyone secretly has" YC archetype. Nobody gets excited about databases at a demo day. But every single growing internet company eventually hits the database scaling wall. Unsexy infrastructure companies that solve genuinely painful problems often build the most durable businesses, because customers can't easily rip them out once installed.

---

Lens 3, The Application Anatomy

What Made Their Pitch Work

Clustrix applied to YC in the Winter 2006 batch, when YC was still finding its identity and Paul Graham was still personally evaluating most applications. The pitch was not complex: