Citus Data, YC Founder Story

Company: Citus Data Founders: Umur Cubukcu (CEO), Ozgun Erdogan (CTO), Sumedh Pathak (VP Engineering) YC Batch: Summer 2011 (S11) Industry: Developer Infrastructure / Distributed Databases Founded: 2011 | Acquired: January 2019 by Microsoft Total Funding: $13M+ (Khosla Ventures, Data Collective, SV Angel, YC) Team at Acquisition: ~45 employees Historic First: First company in the world to donate equity (1%) to an open source foundation

---

---

The One-Line Summary

Three Stanford-trained engineers left comfortable jobs at Amazon and BCG, moved to Istanbul to build in the quiet, and bet everything on a contrarian belief the entire industry had abandoned, that relational databases could scale, and eight years later, Microsoft proved them right.

---

Lens 1, The Before State

Who Were They Before YC?

The three co-founders of Citus Data had everything the startup world considers a "safe" career. They met during graduate school at Stanford, one of the most concentrated startup ecosystems on earth, and then did the opposite of starting a company. They took jobs.

Ozgun Erdogan and Sumedh Pathak went to Amazon in Seattle, where they spent years working deep in distributed systems engineering. Ozgun was particularly shaped by his time on Amazon's internal infrastructure teams, the kind of work where you're dealing with data at a scale most engineers never encounter. He understood firsthand what happens when a database becomes the bottleneck that limits an entire product. Umur Cubukcu chose a different path entirely: he joined Boston Consulting Group, learning the business side of technology, how enterprises think, buy, and scale.

On paper, they had done everything right. Stanford degrees. Prestigious employers. Stable income. Ozgun and Sumedh were building real infrastructure at one of the world's most demanding technology companies. Umur was learning to think strategically about business problems at global scale.

None of this made them happy with the status quo in databases.

The Personal Pain They Were Living

The frustration came from the inside. Ozgun was working on NoSQL data architectures at Amazon, which, in 2010-2011, was the dominant approach to scaling databases. NoSQL was the gospel. MongoDB, Cassandra, Redis, everyone was moving away from relational databases because the common belief was that SQL simply couldn't scale horizontally.

But Ozgun kept hitting the same wall. Every time a team moved to NoSQL to get scalability, they had to give up something fundamental: transactions, joins, foreign keys, the very features that make relational databases so powerful and safe to build on. Engineers were essentially trading correctness and developer productivity for scale.

The question that wouldn't leave him alone was simple and devastating: what if you didn't have to make that trade? What if a relational database could scale out, distribute across multiple machines, without losing the properties that made it trustworthy?

That single question, born from daily frustration inside Amazon's infrastructure, became the foundation for Citus Data.

Why They Almost Didn't Fit the "YC Startup" Mould

Citus Data was not a consumer app. It was not an obvious market. In 2011, database infrastructure companies were not the darlings of Silicon Valley, that era belonged to mobile apps, social networks, and marketplaces. Three engineers building a distributed PostgreSQL extension were unlikely to generate the kind of excitement that YC's application process often rewards.

More importantly, the prevailing consensus in the industry was actively against what they were building. The world had decided that relational databases were a legacy technology. NoSQL was the future. Betting on PostgreSQL as the foundation for a scalable, distributed database was a contrarian position at a time when contrarian bets in infrastructure were hard to fund.

They also had an unusual geographic decision: once they decided to start the company, they moved to Istanbul, Turkey to open their first office. Not San Francisco. Not Seattle. Istanbul, where they could hire strong engineers at lower cost and build product without the distractions and burn rate of Silicon Valley.

Key Insight for Aspiring Founders

The best startup ideas often come from believing a consensus is wrong. In 2011, the entire database industry had agreed that SQL couldn't scale. Ozgun had hands-on evidence at Amazon that the trade-offs being made were real and painful. He didn't need a market study, he needed to trust his own frustration more than he trusted the prevailing narrative.

---

Lens 2, The Idea Origin

How the Idea Was Actually Born

The idea didn't arrive as a flash of insight. It accumulated through years of working on distributed data systems at Amazon and watching the same pattern repeat itself: teams would migrate from PostgreSQL to a NoSQL solution for scalability, then spend months rebuilding in application code the very features the database had given them for free, consistency, joins, constraint enforcement.

Ozgun's core realisation, which he later described clearly in conference talks, was this:

"Scaling compute is easy. Scaling data is hard. NoSQL solves scale but hides enormous costs, you have to re-architect your application, write more code, and give up database guarantees."

The question he posed to himself, and then to Umur and Sumedh, was: what if a relational database could scale out the same way distributed compute does? Not by rebuilding from scratch. By extending the best open source database that already existed: PostgreSQL.

The First Version, An Extension, Not a Fork

This product decision was foundational and deeply non-obvious. Most database startups at the time were either building entirely new databases (costly, risky) or forking PostgreSQL (diverging from the community, creating a maintenance nightmare). Citus took a third path: build as a PostgreSQL extension.

This meant Citus was not a new database. It was a layer that made PostgreSQL distributed. Users didn't have to change their SQL syntax, their ORM, their query patterns. They just installed Citus and their existing Postgres database became horizontally scalable across multiple nodes, sharding data and distributing queries transparently.

The prototype they brought to YC was exactly this: a working extension that distributed PostgreSQL tables across nodes and coordinated queries. It was deeply technical, somewhat rough, but it worked, and it solved a real problem that every growing SaaS company eventually faced.

The Signal That Validated It

The validation came from the market itself. By 2011, the NoSQL wave was beginning to show its cracks. Engineers who had migrated to MongoDB or Cassandra were discovering that application-level joins, transaction management, and constraint enforcement were expensive to implement manually. The "hidden costs of NoSQL" were becoming visible in engineering hours, bugs, and data integrity incidents.

Citus wasn't chasing a trend. It was positioning for the inevitable backlash against a trend, and the timing was exactly right.

The Pattern This Follows

Citus fits a powerful but rare YC archetype: the contrarian infrastructure bet. This is the pattern where a founder has deep domain expertise, watches the industry make a mistake at scale, and builds the alternative the market will eventually need. Other examples: Postgres itself against Oracle's dominance, Linux against proprietary Unix. These bets take longer to pay off, but when they do, the exits are enormous.

---

Lens 3, The Application Anatomy

What Made Their YC Application Work

Citus Data applied to YC Summer 2011 with a working prototype and a thesis that cut against the grain of everything the tech industry was saying about databases at the time. Their application had to do something difficult: convince non-database-experts (YC partners) that a deeply technical contrarian bet was worth funding.

Their core framing was something like:

"NoSQL databases are gaining traction, but they force developers to sacrifice transactions, joins, and foreign keys. We're building a distributed PostgreSQL extension that lets you scale out without those trade-offs."