Deepthi Sigireddi from Supabase

Deepthi Sigireddi from Supabase

Deepthi Sigireddi is a developer with over 25 years of experience. She's worked on Vitess and Multigres. And she now serves as Head of Databases at Supabase.

This article is part of a series interviewing developers (not founders, not executives) working on software infrastructure to understand their work, how they got here, the projects they’re proud of, the incidents they’ve learned from, and what they’re curious about.

Deepthi is a developer with over 25 years of experience. She has worked on sharding projects for both MySQL and Postgres: as the project lead for Vitess at PlanetScale and later on the Multigres team at Supabase. Deepthi now runs the broader database org at Supabase.

What was your first computer? First program you remember writing?#

My first computer was a shared IBM PC at my high school. First programming language was BASIC, and the first program was a simple addition program! Prompt the user to provide two numbers, add them and print the result.

What got you into database development?#

My first couple of years as a professional software engineer had no database involvement. However, around 2000, I started working on supply chain planning solutions for Retailers. The retail supply chain data tends to be massive and stored in either ERP systems like SAP, or in databases like Oracle and DB2. The dataset did not fit into memory on 32-bit unix servers (4GB limit), so I co-invented a solution to this problem that involved partitioning the database, decomposing the dataset, and parallelizing execution across multiple servers.

Without realizing it, I had almost (but not quite) implemented application-level sharding. I spent the next 15 years working on some type of database scaling problem or the other. After supply chain planning, I worked on Mobile Device Management, which had similar scalability issues.

Vitess is not a new project, started in 2010. You were the project lead from 2020-2025, what were you up to during that time?#

During that time, Vitess was like a startup in many ways. We had a maintainer team that did everything from feature development and bug fixes to releases, documentation, website maintenance, performance benchmarking and marketing.

The team shipped reversible online schema changes, major query compatibility improvements, a fully-integrated failover detection and recovery system for high availability, Foreign key support, distributed transactions and performance and reliability improvements to migration workflows.

My contributions during this time were mainly in providing leadership and technical direction. Individual engineers owned various features, I set scope based on our user community and guided design discussions. I also evangelized Vitess in the community at conferences and events, and encouraged and helped the user community to do the same. I also debugged some of the most complex issues we faced in production, being the engineer of last resort.

Why do databases need projects like Vitess and Multigres? Why don’t they just implement these systems themselves?#

That’s a great question. Databases specialize in providing relational guarantees - i.e. ACID properties on a single server. Vitess and Multigres are distributed systems. Providing ACID properties across a distributed system is an incredibly hard problem. Some providers have tried to do this. These are the so-called NewSQL databases like Spanner, Yugabyte, TiDB. They have failed to gain widespread adoption, at least compared to traditional incumbents like Oracle, MySQL and Postgres.

What are the best and worst parts of Postgres and MySQL in your experience?#

The best and worst part of Postgres is the extension system. It is incredibly powerful, which means that it is very easy to misuse it. The actual best part is the open source community.

The best part of MySQL is that it is relatively easy to run and operate. There’s a long legacy of people running it at scale and the pitfalls are well-known. The worst part is the quasi open-source nature which makes it incredibly difficult to get bug fixes into the upstream versions.

How does Multigres differ from Vitess? Or are they architecturally largely the same?#

Multigres and Vitess share a similar architecture in terms of separation of concerns. The differences are more at a detail level. Vitess uses a procedural, heuristic approach to failover, whereas Multigres uses a more comprehensive consensus approach to leader election.

Multigres is early on, and I don’t think sharding (let alone cross-sharded transactions) is yet supported. When do you think we’ll get access to sharded Multigres?#

2027!

Can you tell us about a time you took down production? What happened, how bad was it, what did you learn?#

I can’t claim full credit for this, I had a collaborator. What happened was that we were trying to fix a problem with vtgate (Vitess’ query proxy layer) seeing a stale view of the system. I approved the PR and we deployed it into production. The result was that we went from a stale view of which replica was writable to vtgate’s thinking that there was no healthy database available to serve queries. All queries were returning “no healthy tablet”. It was pretty bad, the system was down for > 24 hours.

I learned to trust my intuition. I was a little iffy about the PR, but trusted that it had been tested enough and thought I was being paranoid. Paranoia is good!

One of the things Vitess and Multigres don’t do, by design, is isolated cross-shard transactions. Can you talk about what that means, the ramifications for users, and why the projects chose not to support this?#

Cross-shard transactions in Vitess went through an evolution. Originally, they were best effort, and if one shard failed, you would be left in an inconsistent state. We eventually implemented a pretty good 2PC based version that was usable, but it didn’t provide isolation.

Isolation for cross-shard transactions is an even harder problem than consistency. The choice was one of expediency. It was a nice-to-have which might have taken the team several years to get correct, and there were more important things to work on.

Regarding this in Multigres, it is still an open question whether we will support isolation. We have to wait and see how things shake out.

A few years ago Supabase bought OrioleDB. Supabase’s CEO recently mentioned on HN you’re still actively working on it. Could you tell us a little about the workloads that might benefit from OrioleDB?#

OrioleDB pretty much eliminates vacuum and bloat. By definition, the workloads that benefit the most are ones which have tables with frequent updates, though even read-heavy workloads might benefit. We just published dbarena.com with OrioleDB benchmarks.

The nice thing about how we did this is that the methodology and source are all available and it should be easy these days (with AI assistance) to replicate these results, and to run any workload you desire through OrioleDB and compare it with vanilla Postgres.

When might we expect OrioleDB to be generally available? And is the vision that OrioleDB would be the default storage engine for all Supabase customers?#

This question is timely because we just announced that OrioleDB on Supabase is Beta. GA timelines will be governed more by reliability and correctness metrics than feature set, but can be expected in 2027.

The long-term vision is to make this the default storage engine for the Supabase Postgres offering, while preserving the ability to opt-out.

How many databases are y’all running at Supabase? What has stood out to you running at this scale?#

We are running 10M+ active databases, with a greater number in a paused state. The problems of running at this scale are entirely different from running thousands of databases. Every inefficiency in fleet management gets magnified, and things that take minutes at the 1000’s scale take hours when you are at millions. Infrastructure that scaled fine no longer scales. Every part of the system has to be optimized, and when you fix a long pole, the next bottleneck shows up.

What’s outside your window at your office? (Wherever that is.)#

Outside my living room is a green area with a distant view of mountains. It is very restful.

Anything you’re excited about coming in Postgres 19 later this year?#

I’m actually really looking forward to seeing how OrioleDB works with async IO in Postgres 18. As far as Postgres 19 goes, WAIT FOR is cool, almost a decade after MySQL.

What’s new and cool coming out of Supabase we should have our eyes on?#

Lots! Keep an eye on Compute, AI evals, and Turso/SQLite.

What are you curious to learn about next? And thank you for your time!#

I’m interested in two opposite ends of the spectrum. On one end is the question of how we can help people get the most out of their largest databases. On the other end are the stresses being brought by agents creating more and more tiny databases and how we’ll deal with them.