Cloudant
Three MIT physicists were moving petabytes of data from the world's largest physics experiment and couldn't find a single tool that worked at that scale. So they built one — and accidentally created the cloud database infrastructure that IBM eventually paid to own.
Michael Miller · 17 min read
Cloudant, YC Founder Story
Company: Cloudant Founders: Michael (Mike) Miller (Chief Scientist), Adam Kocoloski (CTO), Alan Hoffman (Director of Product) YC Batch: Summer 2008 (S08) Industry: Database-as-a-Service / Developer Infrastructure / Cloud Founded: 2008, Cambridge, Massachusetts Acquired: IBM, announced February 24, 2014, closed March 4, 2014 Total Funding: $15.1 Million (pre-acquisition) Post-Acquisition: Now IBM Cloud Data Services
The One-Line Summary
Three MIT physicists were moving petabytes of data from the world's largest physics experiment and couldn't find a single tool that worked at that scale. So they built one, and accidentally created the cloud database infrastructure that IBM eventually paid to own.
Lens 1, The Before State
Who Were They Before YC?
Michael Miller, Adam Kocoloski, and Alan Hoffman were not startup founders. They were researchers. Physicists. People whose daily work involved understanding the fundamental building blocks of matter, not building companies.
Mike Miller described himself plainly: "I'm a philosopher and a physicist by training." He was an Assistant Professor of Particle Physics at the University of Washington. Adam Kocoloski was a researcher and would become Cloudant's CTO. Alan Hoffman, who would become Director of Product, later said the early days involved "leading dual lives: the life of science, and the life of a tech startup, which I wouldn't encourage anyone to do."
Their world was the Large Hadron Collider (CERN) and the Relativistic Heavy Ion Collider (RHIC) at Brookhaven National Laboratory, two of the most complex scientific instruments ever built by humanity. The LHC generates more data in a single second than most companies process in a year. Moving, storing, analysing, and distributing multi-petabyte datasets was not an abstract challenge for these three, it was Tuesday.
The Personal Pain They Were Living
The problem was deceptively unglamorous: the tools for managing big data were awful.
Every time the trio needed to analyse a new dataset from the LHC or RHIC experiments, they faced the same friction. Data was siloed. Moving it required custom scripts. Analysing it in different locations meant rebuilding infrastructure from scratch each time. The databases available in 2007, 2008 were either too rigid (relational SQL), too fragile (didn't scale under heavy load), or simply impossible to distribute globally without heroic engineering effort.
Miller put it simply: "Scientists spend a lot of time building the technology needed to do science", only getting to use those tools for actual analysis much later. The overhead was consuming their research lives. So they started building something better, first for themselves.
They discovered CouchDB, an open-source, document-oriented NoSQL database built for distributed systems. It was promising but needed to be pushed much further. So they built BigCouch: their own open-source, fault-tolerant, clustered, globally scalable extension of CouchDB that could handle the demands of particle physics research.
They didn't plan to turn it into a company. They were just trying to do their jobs.
Why They Almost Didn't Look Like Startup Founders
Three physicists from MIT applying to a Silicon Valley startup accelerator in 2008 was genuinely unusual. YC's typical profile at the time skewed toward young hackers building consumer web apps, not tenured researchers building distributed database systems. Miller, Kocoloski, and Hoffman were academics first. They had no prior startup experience, no business background, and were still employed full-time in research when they applied.
There's a particular kind of imposter syndrome that comes with being deeply technical but having no startup credentials, no prior exit, no famous founder-friends, no network in Silicon Valley. These three had none of that. What they had was a working system handling some of the most demanding data workloads on earth, and the insight that if particle physicists needed it, so would everyone building mobile and web apps.
Key Insight for Aspiring Founders
The best startup ideas come from the most unsexy places. Nobody reads physics research papers looking for startup inspiration. But three researchers staring at petabytes of collider data saw a universal developer problem years before anyone in Silicon Valley was talking about it. Your deep domain boredom is someone else's billion-dollar pain point.
Lens 2, The Idea Origin
How the Idea Was Actually Born
There was no single "aha moment." The idea emerged through accumulated frustration over years of working with data that modern tools couldn't handle.
In 2007, while working on data problems at the LHC, which generates extraordinary volumes of collision data per second, Miller, Kocoloski, and Hoffman found CouchDB. It was elegant in design but not remotely ready for production-scale distributed workloads. So they began extending it.
What became BigCouch, and eventually Cloudant, started as internal research infrastructure. The three were solving a problem in front of them: how do we store, replicate, search, and analyse massive datasets across geographically distributed systems without everything breaking?
The pivot from "research tool" to "startup" happened when they asked a different question: "If we need this so badly, who else does?" The answer, they realised, wasn't other physicists, it was every developer building web and mobile apps that needed data to live reliably in the cloud. The specific insight was that mobile computing was about to explode, and most developers had no good way to manage the data behind their apps at scale.
Their idea in one sentence: take the infrastructure we built to survive particle physics, clean it up, and sell it as a service to anyone who needs their database to never go down.
The First Ugly Version
The first version was, strictly speaking, a research tool, not a product. BigCouch was open source, written for scientists who understood distributed systems. It had no onboarding, no documentation designed for non-physicists, no support infrastructure, and no pricing.
Getting from "research tool used by physicists at CERN" to "product a developer could sign up for in three steps" required them to completely rethink who they were building for. The original users were their colleagues. The new users were developers who had never heard of the Large Hadron Collider and didn't care.
The real insight buried in this ugly first version: they already had proof that the core technology worked at the absolute extreme end of scale. Most database startups spend years proving their system doesn't collapse under load. Cloudant's system had already survived CERN.
The Signal That Validated It
The signal wasn't a sudden surge of users. It was quieter: YC's interest itself.
When the team's work on big data caught the attention of Y Combinator in early 2008, it validated something important, the problem they were solving in academic research was commercially relevant. YC's investment in them was a signal that people outside of particle physics saw the same infrastructure gap they did.
The second signal was how developers responded when Cloudant eventually launched a free tier in August 2010. Developers didn't need to be educated on why reliable, scalable, globally distributed data was valuable. They had been struggling with exactly this problem and simply hadn't had a clean managed solution. Word spread quickly through developer communities.
The Pattern This Follows
Cloudant is a textbook example of what YC calls "research-to-startup", a pattern where deep technical work done in academia or advanced research environments produces tooling so good it has obvious commercial application. Other famous examples from this pattern include Google (search infrastructure from Stanford), and many open-source database companies. The key is that the research bona fides aren't just a story, they're a real moat. Competitors couldn't replicate the depth overnight.
Lens 3, The Application Anatomy
What Made Their Application Work
Cloudant applied to YC Summer 2008, a period when "big data" was just beginning to enter the mainstream technology conversation. Hadoop was new. NoSQL was barely a word. The idea that developers would pay for managed database infrastructure delivered as a service was not obvious.
What made their application compelling was the combination of:
-
A genuine, lived problem, not a market-research hypothesis. These founders had personally struggled with exactly the problem they were solving, at a scale no one could argue with. "We built this to handle data from the Large Hadron Collider" is not a sentence you hear in many YC applications.
-
Working technology, BigCouch was already built and running in production for physics research. This was not a deck with a vision. It was a functional system that had already survived real-world extreme conditions.
-
A clear pivot from edge to mainstream, they could articulate why particle physics infrastructure applied to web developers. The jump from "CERN researcher" to "mobile app developer" is non-obvious, but once explained, it's immediately obvious.
The One-Liner That Worked
"We're three MIT physicists who built distributed database infrastructure for the Large Hadron Collider, and we're turning it into a managed service so any developer can have the same data reliability without the engineering overhead."
Every part earns its place:
- MIT physicists, instant credibility on technical depth
- Large Hadron Collider, makes the scale undeniable
- Managed service, defines the business model clearly
- Without the engineering overhead, names the pain directly
What They Had vs. Didn't Have
| Factor | Cloudant's Reality |
|---|---|
| Revenue | None |
| Paying customers | None at application time |
| Working product | ✅ Yes, BigCouch running in live physics research |
| Technical credibility | ✅ Exceptional, MIT, CERN, RHIC |
| Market validation | Emerging, "big data" just becoming a concept |
| Business experience | None, first-time founders, all from academia |
The lesson: extraordinary technical proof can replace traction if the domain credibility is unimpeachable. No one was going to question whether these three understood large-scale distributed data problems.
Application Scorecard
| Dimension | Score | Notes |
|---|---|---|
| Clarity of problem | ⭐⭐⭐⭐⭐ | "Databases break at scale" is universally understood |
| Founder-market fit | ⭐⭐⭐⭐⭐ | Literally built the tech for one of the most data-intensive experiments on earth |
| Traction proof | ⭐⭐⭐ | Working tech, no paying customers yet |
| Market size framing | ⭐⭐⭐⭐ | "Every web and mobile developer", enormous but correct |
Lens 4, The Interview Moment
The Hardest Question They Faced
For a team of three MIT physicists applying to a startup accelerator, the hardest question was never about the technology. The technology was bulletproof. The hardest question was always the commercial one: "Who actually pays for this, and why now?"
In 2008, managed database services were not yet a standard line item in a developer's stack. AWS was still new. The concept of paying someone else to run your database in the cloud was not yet obvious or normalised. YC partners would have pushed hard on whether the founders understood the go-to-market path, because brilliant infrastructure means nothing if you can't get developers to adopt it and enterprises to pay for it.
The founders' honest answer to this was rooted in developer empathy: Kocoloski noted that "physicists and other scientists are natural problem solvers, they're really good at thinking through what kinds of tools will work for particular data challenges." They brought that same rigour to understanding the developer's data problem. They weren't guessing at what developers needed. They had lived it.
The Turning Point
The turning point in Cloudant's early life was less about a single interview moment and more about a strategic insight during the YC batch: the market they were building for was not today's developers, it was the developers who would need mobile-first, globally distributed data infrastructure in two to three years.
This was the bet. And the bet required patience that most YC companies don't exercise. Cloudant spent time after YC not chasing rapid consumer growth, but building deeply: improving the CouchDB core (eventually releasing BigCouch as open source), building out documentation, and targeting the specific developer who was hitting the wall of traditional SQL databases and needed something better.
The Interview Archetype
Cloudant's interview fits the "prove the timing is right" archetype. Their technology was clearly credible. The question YC needed answered was: "Why is 2008 the right moment for this?" The right answer, that mobile computing was about to create a flood of developer teams who would need exactly this infrastructure and have no good options, turned out to be exactly right. The timing bet paid off.
Lens 5, The Batch Experience
What The YC Batch Actually Gave Them
Cloudant went through YC Summer 2008 and received the standard seed funding of $20,000. For three MIT researchers accustomed to grant cycles and academic timelines, the YC batch was a genuine cultural shock, a forcing function that compressed timelines and demanded commercial urgency they hadn't needed before.
Alan Hoffman's description of those early days captures the difficulty: they were "leading dual lives: the life of science, and the life of a tech startup", still working in their research roles while simultaneously trying to build a company. The YC batch made clear that you cannot do both indefinitely. At some point, the company either becomes the main thing, or it doesn't become anything.
The batch also gave them something harder to quantify: a community of other technical founders who were willing to try their product. The first developer users of Cloudant came largely from within the YC ecosystem, founders and developers who trusted that a YC-backed, MIT-pedigreed team had built something serious.
The Shift During the Batch
The biggest shift during and immediately after the batch was the decision to open-source BigCouch. This was not an obvious call. Open-sourcing your core technology means competitors can study and copy it. But the Cloudant team made the bet that being the primary contributors and maintainers of the open-source project, and offering the managed, hosted version as the premium product, would create more trust and adoption than keeping it closed.
This was exactly the right call. Open source gave Cloudant credibility with the developer community in a way that no marketing budget could have bought. Developers evaluated the code directly, saw its quality, and adopted it. The managed service became the obvious "lazy path" for teams who wanted CouchDB's architecture without the operational overhead.
Post-Batch Growth
- August 2010: Free tier launched; open-source BigCouch released
- August 2010: $1M seed round from Avalon Ventures
- November 2010: Named one of "10 Cool Open-Source Startups" by CRN
- December 2011: Additional $2M in funding
- 2012: Second major round raises $12M, led by Devonshire, Rackspace, Toba Capital, with In-Q-Tel (the CIA's venture arm) and Samsung participating
- 2014: Acquired by IBM, joining IBM's Information and Analytics Group
The CIA's In-Q-Tel investing was a particularly notable signal: intelligence agencies handling national-security-grade data workloads needed exactly what Cloudant built. If it was good enough for CERN and the CIA, it was good enough for anyone.
Lens 6, The Mindset Shift
The Limiting Belief They Had to Kill
Mike Miller, Adam Kocoloski, and Alan Hoffman came from a world where rigour was everything. Academic culture rewards thoroughness, peer review, and careful publication. You don't ship until it's right. You don't claim something works until you can prove it in a paper.
Startup culture is the near-opposite. The limiting belief they had to kill was: "We should wait until it's production-perfect before anyone uses it."
They had spent years building infrastructure that genuinely was production-perfect, for one of the most demanding environments on earth. But the risk they ran was the academic trap: building forever, never launching. YC forced them to invert this. Ship early. Get real developers using it. Learn from production usage by real people, not from theoretical requirements gathered in a lab.
The Uncomfortable Action
The most uncomfortable thing Cloudant did was open-source their core competitive advantage.
BigCouch, the technology that differentiated them, that they'd spent years building, became public code that any competitor could read, fork, or build upon. For researchers trained to protect intellectual contribution (academic credit is everything in science), putting your best work into a public repository for anyone to use felt professionally exposed.
But the move worked. By becoming the primary stewards of an open-source project used by thousands of developers, Cloudant owned something more valuable than closed code: they owned the community's trust. IBM didn't acquire Cloudant for its proprietary technology. IBM acquired Cloudant for its position in the CouchDB ecosystem, its relationships, its reputation, its team.
The Identity Shift
Before Cloudant, these three thought of themselves as scientists who used data tools. After Cloudant, they became the people who built data tools that others used.
Mike Miller's own language captures the shift. After the IBM acquisition, he described himself as a "recovering particle physicist and distributed systems developer", with recovering used deliberately, the way someone frames a prior identity they've moved on from.
He went on to co-found Liquid 2 Ventures, investing in hard tech and enterprise infrastructure companies. The physicist's mindset, comfort with complexity, long time horizons, belief that the unsexy fundamental problems matter most, became the thesis of his investing career.
The shift is: stop building tools to survive your own problem. Start building tools so others can survive theirs.
The Transferable Principle
Open source your moat before someone else copies it closed.
Cloudant's open-source bet seems counterintuitive, why give away what you worked hardest to build? But the logic holds in developer infrastructure: the community that forms around open-source adoption creates a moat no proprietary system can replicate. Your competitive advantage stops being "we have technology no one else has" and becomes "we are the people everyone trusts to maintain and improve this technology." That trust is not copyable. The code is.
Lens 7, The Replicable Playbook
Action 1, This Week: Map Your "Accidental Infrastructure"
Cloudant was built as internal tooling before it was ever a product. Look at what you've already built, scripts, systems, workflows, tools, that you use in your own work to solve a problem others face too. The question is not "what should I build?" but "what have I already built that other people would pay for?"
Specifically: identify one piece of infrastructure, tooling, or process you've built for yourself that took you weeks or months to figure out. That effort is the signal. If it was hard to build, it's valuable to others who face the same problem but don't have your background to solve it.
Action 2, This Month: Find Your "Edge to Mainstream" Bridge
Cloudant's insight was that infrastructure built for physics research applied directly to web developers. The jump wasn't obvious, particle physics and mobile apps seem completely unrelated. But the underlying data problem was identical.
Look at your domain expertise, however niche or technical it seems, and ask: who else has this exact problem, just in a different industry or context? The further your expertise is from mainstream tech, the less competition you'll face when you make the bridge. Write a 500-word explanation of your problem for a completely non-specialist audience. If you can make a non-physicist understand why the LHC's data problems apply to their mobile app, you've found your story. If you can't explain it simply, you haven't found the bridge yet.
Action 3, Before Applying to YC: Build the Technical Evidence First
Cloudant did not pitch an idea to YC. They pitched working technology that had already survived extreme real-world conditions. If you are a technical founder, the single most powerful thing you can do before applying to YC is to have something running, even if it's rough, even if it has no users, that you can show, demo, or point to in production.
YC partners see hundreds of "ideas" every cycle. A working system, even a small, imperfect one, puts you in a completely different category. Miller's specific advice to founders is to focus on hard tech, foundational infrastructure, and problems where your deep expertise gives you a genuine edge no generalist can replicate. That specificity reads clearly in a YC application.
Story Relevance Tags
| Tag | Applies? |
|---|---|
| Technical founders | ✅ Yes, deeply so (MIT physicists) |
| Non-technical founders | ❌ No |
| Solo founder | ❌ No, Three co-founders |
| Pre-revenue at application | ✅ Yes |
| First-time founders | ✅ Yes, no prior startup experience |
| Academic / research background | ✅ Yes, rare and valuable angle |
| B2B | ✅ Yes |
| Open-source strategy | ✅ Yes, core to growth |
| Acquired exit (not IPO) | ✅ Yes, IBM acquisition |
| Non-US origin | ❌ No, US-based team |
3 Things You Can Screenshot Right Now
"Build your moat in public. Cloudant open-sourced their core technology, the thing they worked hardest on, and that act of openness created more trust than any proprietary lock-in could have. Community trust is not copyable. Code is."
"Your deep domain boredom is someone else's billion-dollar pain point. Three physicists frustrated by database tools built infrastructure that IBM paid to own. The most unsexy problem in your field might be the most important startup you could build."
"Don't pitch an idea to YC. Pitch working proof. Cloudant walked in with technology already running in production at one of the most data-intensive experiments on earth. That's a different conversation entirely."
More stories every week.
Get 2 free stories in your inbox each week.