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."

The power of this pitch was the implicit insight it revealed about the founder: Ozgun had worked at Amazon's distributed systems team. He had seen the NoSQL trade-offs from the inside, not from a blog post. That founder-market fit, deep insider knowledge of a painful technical problem, is one of the signals YC weights most heavily in infrastructure applications.

What They Had at Application Time

The lesson here is one of the most important in this entire series: you don't need the market to agree with you at application time. You need the partners to believe you understand why the market is wrong.

What They Did NOT Include

Citus did not oversell the market size. Infrastructure companies that try to pitch "trillion-dollar database market" language in early-stage applications often come across as hand-wavy. The Citus founders kept their pitch grounded in the specific engineering problem, distributed SQL without the NoSQL trade-offs. The market size was implicit and obvious to anyone who thought it through. They let the partners do that math.

Application Scorecard

---

Lens 4, The Interview Moment

The Hardest Question They Faced

For a company building database infrastructure with no consumer appeal and no traction, the hardest question in any YC interview is always a variation of: "Who is going to use this, and why would they trust a two-year-old startup with their production database?"

Databases are not casual products. They hold a company's most critical data. Enterprises don't experiment with new database technology on a whim, the cost of a database migration gone wrong can be existential. Convincing a YC panel that any startup could break into this market required answering not just the product question but the trust question.

Citus's answer lived in their prototype and their pedigree. They weren't asking companies to trust a vision. They were asking them to install an extension on top of the database they already trusted: PostgreSQL. The risk surface was dramatically smaller than adopting a new database entirely. That reframing was their most important interview asset.

The Turning Point

The strategic insight that likely carried the Citus interview was their non-fork architecture. When YC partners understood that Citus didn't require companies to abandon PostgreSQL, that it was an additive extension, not a replacement, the risk objection largely dissolved.

The interview archetype here is the "de-risking" interview: where the key question is not "is this a good idea" but "can this team convince a skeptical enterprise customer to try it?" Citus answered that question architecturally, not just verbally.

What They Wish They Had Said Earlier

In retrospect, the Citus team's biggest early challenge was not the product, it was communicating to non-technical buyers why "worry-free Postgres" mattered. Database buyers inside enterprises are often not engineers. They're infrastructure leads and CTOs who think in terms of risk, cost, and vendor relationships. Framing the product in terms of reducing engineering hours spent on database workarounds, rather than technical architecture, would have shortened early sales cycles.

Interview Archetype

The "Trust Infrastructure" Interview, YC partners were really testing one thing: could these three engineers build something that enterprises would trust with their most sensitive asset, their data? The answer was yes, and the non-fork architecture was the proof.

---

Lens 5, The Batch Experience

Istanbul First, Silicon Valley Later

One of the most distinctive elements of Citus Data's founding story is their decision to open their first office in Istanbul, Turkey, immediately after deciding to start the company. While they would eventually relocate to San Francisco for the YC batch and beyond, Istanbul allowed them to hire strong engineers at a lower burn rate and build product with focus.

This is a playbook more international founders are running today, build the early product somewhere you can afford to be wrong cheaply, then move to where the customers and capital are when you're ready. Citus executed this before it was fashionable.

What YC Actually Did for Them

By the time they graduated the S11 batch, Citus had a prototype and a vision. What YC provided was threefold:

Credibility with enterprise customers. Being a YC company opens doors in the Bay Area enterprise market that would otherwise take years of relationship-building to unlock. For a database infrastructure company trying to get Fortune 500 engineers to trial their product, the YC stamp was a meaningful trust signal.

Access to early adopters. The YC network of companies, fast-growing SaaS businesses that were starting to hit database scaling pain, was the perfect early adopter pool. These were exactly the companies that would feel the NoSQL trade-off pain first and be most open to a PostgreSQL-native solution.

Forcing function on narrative. YC's Demo Day process forces founders to articulate their value proposition in two minutes. For deeply technical founders, this is often the most painful and most valuable exercise of the entire batch. It compels you to translate engineering precision into business language.

Ozgun captured the arc of what they walked in with: "It was around 7 years ago that we graduated from Y Combinator with a prototype and a vision. We wanted to make it so that developers would never have to worry about scaling their databases again."

Growth During and After the Batch

The trajectory from YC to acquisition maps a patient, methodical build:

• 2011: YC S11 batch, prototype, no revenue
• 2012, 2015: First enterprise customers, open source traction grows, Chartbeat, Agari, and others adopt Citus
• 2015: Series A led by Khosla Ventures and Data Collective, $6.2M
• 2016: Citus Cloud launched (fully managed service)
• 2018: 1% equity donated to PostgreSQL non-profits, millions of downloads
• 2019: Microsoft acquisition, team of 45, undisclosed price

The patience in this timeline is instructive. Citus did not grow explosively. They grew deliberately, building trust in an industry that does not move fast.

---

Lens 6, The Mindset Shift

The Limiting Belief They Had to Kill

The dominant belief in 2011 was: "Relational databases are legacy technology. The future is NoSQL."

This wasn't a fringe opinion. It was being voiced by engineering teams at Google, Amazon, Facebook, and Twitter. The thought leaders of the era were evangelising Cassandra, HBase, and MongoDB. Choosing to bet your company on PostgreSQL in 2011 was the equivalent of betting on film cameras in 2007.

What Ozgun, Umur, and Sumedh had to believe, in the face of overwhelming industry consensus, was that the people promoting NoSQL were solving a real problem (scale) but creating a larger one (complexity, correctness, developer productivity). They had to trust that this trade-off would eventually become visible and painful enough that the market would want an alternative.

That belief required genuine intellectual courage. Not stubbornness, courage. There's a difference: stubbornness ignores evidence; courage interprets existing evidence differently from the crowd.

The Uncomfortable Action

The most unconventional thing Citus did was their open source equity donation in 2018. Before the acquisition, while still a private company with no liquidity event in sight, they donated 1% of Citus Data's equity to the PostgreSQL non-profit organisations in the US and Europe.

This was, to their knowledge, the first time any company in the world had donated equity to an open source foundation.

The logic was both principled and strategic. Principled: PostgreSQL was the foundation their entire product was built on. They had built a business on open source and felt an obligation to give back in a meaningful way, not just code contributions or conference sponsorships. Strategic: aligning themselves irrevocably with the PostgreSQL community positioned Citus as the most committed commercial actor in the Postgres ecosystem, which mattered enormously when enterprise buyers were choosing which PostgreSQL solution to trust.

The Identity Shift

The Citus founders consistently described themselves not as a "database company" but as a company with a mission: "to make it so that developers would never have to worry about scaling their databases again."

That reframe, from product company to mission company, changed how they hired, how they marketed, and how they engaged the Postgres community. They weren't selling software. They were recruiting developers into a belief that scalable, reliable, relational databases should be a solved problem.

Patrick Collison described Stripe as wanting to "grow the GDP of the internet." Umur's version of that was to "grow the GDP of what developers can build without worrying about the database." Different domain, same philosophy.

The Transferable Principle

Build on top of something people already trust, then extend it.

Citus didn't ask the market to trust a new database. They asked the market to trust PostgreSQL more, and gave them a reason to. Every great infrastructure company finds the thing developers already love and removes the ceiling on what it can do. Don't ask people to abandon what they know. Build the upgrade path.

---

Lens 7, The Replicable Playbook

Action 1, This Week: Find the Hidden Cost in Your Industry's "Winning" Solution

Every market has a dominant approach that everyone accepts, and that approach has hidden costs that practitioners quietly complain about but rarely make into products. In 2011 the NoSQL movement was winning, but Ozgun could see the complaints stacking up inside Amazon's engineering org.

This week: identify the dominant solution in the problem space you're working in. Then talk to 5 engineers or practitioners who use it daily. Don't ask "what's wrong with it?" Ask: "What do you spend time on that you wish you didn't have to?" The hidden costs live in the answers to that question. That's your market.

Action 2, This Month: Validate the Contrarian Thesis With Insiders

Citus was built on a contrarian belief, that SQL could scale. Before starting the company, the founders had direct evidence from inside Amazon. They didn't need external validation because they had internal proof.

If you're building something that goes against prevailing industry consensus, you need at least 3-5 people with deep domain expertise, not friends, not generalists, who independently agree the consensus is wrong. This month: find those people. They exist in engineering Slack communities, at conferences, in company alumni networks. If you can't find practitioners who agree the problem is real, you may be building for a thesis, not a market.

Action 3, Before Applying to YC: Build on Top of Existing Trust, Not Against It

The single architectural decision that made Citus fundable, and ultimately acquirable by Microsoft, was that it was an extension, not a fork or replacement. It asked nothing of existing PostgreSQL users except to install one more package.

Before you apply to YC, ask yourself: is your product asking people to trust you, or to trust something they already trust, with your addition? The second is dramatically easier to sell, support, and scale. Citus didn't have to build trust from scratch. PostgreSQL had 20 years of it. They just added distributed scale on top.

Story Relevance Tags

---

3 Things You Can Screenshot Right Now

"Build on top of something people already trust, then extend it. Don't ask the market to abandon what it knows. Give it a reason to trust what it knows even more."

"The best startup ideas often come from believing a consensus is wrong, and having insider evidence that the hidden costs are real. Ozgun didn't read about NoSQL trade-offs in a blog post. He lived them inside Amazon."

"Citus donated 1% of its equity to open source before any acquisition, before any liquidity. Giving back before you capture value is not charity, it's the deepest form of community alignment. And communities acquire companies."

---

What Made Citus Acquirable, And What You Can Learn From It

The Microsoft acquisition of Citus Data in January 2019 was not a surprise exit. It was the logical conclusion of a deliberate strategy: become the most trusted commercial actor in the PostgreSQL ecosystem, then become part of the infrastructure company that needed Postgres most.

Microsoft, under Satya Nadella, had pivoted to open source. Azure needed a world-class managed PostgreSQL offering. Citus had built exactly that, plus the credibility with the Postgres community that no Microsoft internal team could replicate. The acquisition was not a rescue, it was a logical fit between two organisations that had built aligned trust with the same developer community.

For aspiring founders: community trust is acquirable by larger companies, but not replicable. If you build genuine credibility in an open source or developer community, you create an asset that corporate acquirers will pay a premium for, because they know they cannot build it internally.

---