Supabase Select 26 Main Stage

Please welcome CTO and co-founder of Supabase, Ant Wilson.

Hey everyone, welcome to Supabase Select 2026. We are back at YC this year in San Francisco, the spiritual home of builders. Welcome to everyone who's joining via YouTube and welcome back to everyone who was here last year.

So last year we had some phenomenal conversations. We had Patrick from Stripe, we had Dylan from Figma, we had Guillermo from Vercel, and we were like, how are we possibly going to top it this year? But somehow I think we've actually managed to do it. This year we've got some of the most amazing builders. We've got Andrew, we've got Garry Tan, we've got the folks from Anthropic, OpenAI, Replit. But that's not all. We've got the... I have no idea what we're going to do next year. Like, how do you beat this?

So I want to start off by talking a little bit about the growth in the Supabase community. We now have more than 13 million builders running their backends on the Supabase platform, and the number of databases now under management is about to rocket past 45 million Postgres instances.

That's more than five times where we were last year. And this isn't just Postgres-compatible or shared-everything architecture. This is 50 million dedicated Postgres clusters used by startups and enterprises and individuals around the world.

And since we're in YC, it's worth calling out that Supabase is now used by more than 1,700 Y Combinator companies, including 60% of the most recent batch. And it's not just startups, it's enterprises, governments, healthcare providers around the world.

And now we have a huge partner network also helping us reach more and more builders. You'll see a bunch of the partners in the partner space outside, and through the partner integrations we're bringing Postgres and Supabase to an even wider network of builders. And so let's look at one example.

You're building a new project. What's the first thing you need after you choose your database? It's payments. And so we're working now together with Stripe, and we're proud to announce that Supabase is now a destination for Stripe data pipelines. So Stripe data pipelines give you the ability to sync all of your Stripe data into your Supabase instance directly from the Stripe dashboard.

And another great example of partner engineering was announced by Sam this week at OpenAI's DevDay. You can now log into Supabase using your ChatGPT account. Meaning agents can log in, deploy, and start loading data into Supabase without ever leaving the ChatGPT interface. You know, we spent the first five years of Supabase building this really great dashboard, and we poured our hearts and minds into building the best possible dashboard. And now the agents just don't care. They just want to connect via ChatGPT.

And we've teamed up with xAI to launch Supabase on the Grok bot and Grok build. And we're working closely with Google to bring Supabase more directly into the Gemini ecosystem.

But by far the most important part of the Supabase community is you guys. The individuals that contribute, they advocate, they help moderate in the community every single day.

Last year, we announced that we wanted the community to share in the success of Supabase, the company. And originally, we wanted to give the community members the ability to invest in Supabase. And it's taken us an entire year to figure this out. But we're finally proud to announce that we're rolling out the Supabase community scheme, and we've issued the equivalent of a million dollars worth of Supabase stock to be given away to our most valuable community members. No investment necessary.

And by way of ceremony, we want to announce the first recipient on the Supabase community scheme. If you've ever been in the Supabase Discord, you might recognize this icon. So this is the icon of Gary Abbott, also known as Gary Austin online.

So over the course of the last six years, Gary has answered over 20,000 questions in the Supabase Discord alone. 13,000 of these questions he answered within an hour of them being asked. And Gary's median response time is 22 minutes. Like this guy doesn't sleep. He's the original Grok bot. So big round of applause for Gary for being a legend.

Gary's at the back. Gary, give us a wave. Amazing.

So without further ado, to talk more about the Supabase journey, I'm going to invite my co-founder and Supabase CEO Paul Copstone to the stage.

Okay, welcome everyone. Welcome again to Supabase Select. Thanks Gary for coming and also to all the community members. I've actually met a few of you. I'm looking forward to hanging out with all of you later today. And we're here. It really is a good vibe right now in San Francisco and especially here in Y Combinator. And this is where it all started for us, of course, here at YC in 2020.

And a little story that Ant touched on when we got started: we got into YC and we had 100 days till demo day. And I said to one of our employees, Josh, you have 100 days to build a Postgres dashboard that feels as simple to use as Airtable. And so he did that, and we started as a dashboard-first company, and that was 2020.

Since then, two things have changed. First, it's completely ridiculous to spend 100 days building a dashboard. Now, this should be done in like two minutes. The second thing is that dashboards are no longer the best developer experience.

At the start of this year, it became pretty clear that the ground's shifting beneath the industry's feet, not just ours. And we've spent the last six years building the world's best developer experience. But we know we need to build for our newest type of user, which is agents.

So agents don't use dashboards. They are code-first and they're Git-native. We set out to build the platform where we can meet the agents where they excel in code. Our vision for the agentic era is to be this code-first, Git-native platform.

This is a memo that I wrote to the team at the start of the year, a bit of inside baseball. And to read it verbatim: we believe that all of Supabase needs to be managed in code. The Supabase folder needs to be the source of truth. Users should be able to push to a Git remote and everything updates. The dashboard, the API, the CLI, and Git, all of them need to work in lockstep. So a change anywhere should update everywhere.

Ultimately, though, it isn't agents who build, it's you guys, the builders. So everything we're announcing today is in service of our mission to be there when you get started and to help you scale from prototype to petabyte.

All right, so let's get into it. We're going to cover three themes today: build, operate, and scale. And we're going to start with the build section.

Let's start code-first. So with the latest models, humans are writing less and less code. And actually, we use a lot of SQL inside Supabase. You use a lot of SQL inside Supabase. And SQL is actually one of the agent superpowers because it is structured. It is very good for agents.

That said, agents are not great at understanding the shape of your database. Currently, the source of truth is a very long history of migration files, and reading that folder eats up a lot of the context and it creates a source of hallucination. This would be like reading your Git history from every single change instead of just reading the contents of your code folder.

The only accurate way to understand your database at the moment is to start up your Postgres server and then introspect it directly. But that's really slow, and you need a running database every single time. So we're stuck between a rock and a hard place. Either you have to read the entire history with hallucinations, or you have to stand up a really slow database.

So what we need to do is a way to assert the schema of the database inside code, and we need to make it accessible to both you, the humans, and to the agents at a glance. And so today we're introducing declarative schemas again.

Under the hood, we've completely redesigned declarative schemas using our built-in-house diffing tool called PG Delta. Compared to our previous iteration, PG Delta covers almost all of the Postgres object types. It makes it the most complete diffing tool on the market today.

So here's how PG Delta works. You start with one command, and it moves your entire database structure into code. What you get back is every single object of your database represented inside files. The files contain everything. They're your tables, they've got views, they've even got your database comments directly inside the code. Your folder essentially becomes the source of truth, and it enables you to make the changes and to review the changes that your agents make with absolute confidence.

So declarative schemas powered by PG Delta is available in our new CLI. But importantly, PG Delta isn't just for Supabase. The library, as with everything we do, is completely open source, and you can use it with any Postgres database, Supabase or otherwise.

Okay, so we've got the database in code, but you also want to run it fast. And Supabase is a batteries-included platform. Historically, running a full stack means running all of the services on your laptop at the same time. And this is quite heavy. So we wanted to solve this.

We have rebuilt our CLI from the ground up to solve this problem. So running through a whole set of new features that we've added to our CLI today. Cold starts on the new CLI are nine times faster. It uses... I don't know where I'm supposed to point for this clicker to work, but I think I just clicked 10 times. All right. It uses nearly 90% less idle memory, and it's five times smaller on initial download.

Additionally, the new CLI runs natively on the operating system, so you can use it without Docker images. This has been one of the biggest complaints, and we know it's been super heavy, so it's pretty cool to move it to native. The native CLI also enables lazy loading. This means that each service only starts when a request comes in, rather than booting all of the services at once. And these gains have been even better when you're running multiple agents.

So historically, running Supabase locally means running only a single instance. And then if you attempt to spin up a second or third instance, you have these port conflicts. So we have added multi-agent support for parallel agents and also for workflows and Git worktrees. But we're not just focused on local development.

Agents have moved to the cloud. They run for longer, they run in parallel, and they keep going after you close your laptop. And so with the slimmer CLI, with native support and lazy-loaded services, we've optimized the Supabase experience for cloud agents.

All of these features and more are part of our latest CLI, so you can download that today.

Okay, shifting gears. Let me tell you a little story about this guy called Garry. So, if you don't know, Garry's a YC partner. He runs Y Combinator, where we're having this talk today. He'll be joining us later on for a fireside chat. He's going to be talking about startups in the AI era. So that'll be super interesting.

But actually, Garry was building something earlier this year, and he sent me an email. He developed this application. It's called GBrain. It's a shared memory and knowledge layer for agents to store, connect, and retrieve data. It's like a digital second brain.

He started actually building it on Supabase, but he ran into this issue. He was trying to perform long-running tasks. The task was chunking and embedding. This is where you take your content, you break it up, you turn it into embeddings, and then you store it inside your Postgres database. So he sent me this email, and I said, Supabase Edge Functions are the obvious choice for this, but the two-second limit is a big downside, and it might force me to add a server elsewhere.

Garry is not alone in this frustration. We have heard this for quite a while, numerous years, that the two-second limit is not enough, and we've heard that the Deno runtime was too restrictive for most of your use cases. So for years now, you've been asking for a more flexible and a more powerful solution. And that's why today we're announcing Supabase Compute.

So with Supabase Compute, you can run anything. There are no timeouts, it's completely serverless, and it's colocated right next to your database. Let's go back to Garry's problem to see how it could solve this problem.

So first of all, you simply write your code inside a new compute directory, which is inside the Supabase folder. You can use any runtime. So it can be Node, it can be Rust, it can be Python, whatever you or probably your agents are writing these days, probably Rust. Then you simply update the Supabase config file, and you can specify the resources you need. So in this case, we're going to add two gig of RAM and one CPU, and that's basically it.

You just use the CLI, and that will do the bundle and deploy part of your code. And just like that, Garry's problem is solved. GBrain can perform long-running tasks like chunking and embedding. There are no limits on how long compute instances can run. And because it's all CLI-driven, you actually don't need to write any of the code. The agents can write and deploy the code for you.

Not only that, some tasks are better done in parallel. So Supabase Compute can natively spin up multiple compute instances. To do this, you simply change your config file, and you can redeploy. And importantly, more instances don't mean more costs. Your compute becomes idle when it's not in use, and you're only charged for the time that it's actually in use.

Another really important feature, because we're a database company, is colocation. So accessing your database needs to be really fast. Supabase Compute can be colocated exactly next to your database inside the same private network.

Most applications are extremely chatty with the database, and they make multiple round trips from the API, for example, to the database. So compute is less than 10 milliseconds away from your database, and it has direct Postgres access, which is something, by the way, that most other sandboxes don't have. So this makes compute great for hosting your API.

In fact, the speed, flexibility, and scalability of Supabase Compute makes it perfect for almost anything. You can run agents, you can offload heavy tasks, and of course, you could even run GBrain with it.

So today we released Supabase Compute in private alpha. It supports any runtime, any workload, and it's all milliseconds away from your database.

Okay, we ship these features to help you build faster and operate better, but we've been focused on ways to help you operate. So we're going to do a lightning round. We've got a lot of content to get through today, and I want to cover some scale stuff at the end. So I'm going to whip through basically eight features now in a bit of a lightning round. Let's get into it.

All right, logs. Logs are more important than ever before. So they contain really critical context, especially when you're building your agents, they want to know what's happening, especially when there are problems. So today we've released a new MCP tool which will allow you to read your logs directly via our MCP.

The second one, sometimes SQL snippets don't provide enough context. So we're introducing notebooks. Notebooks are like smart documentation. You can write SQL queries, you can build charts, you can have written content directly inside them. And you can create these notebooks yourself, or you can even ask the agents to create them for you. And of course, these notebooks can be shared across your team right inside the dashboard.

Supabase provides a collection of advisors already. These make your application fast and secure. And today we're releasing a new collection for health monitoring. These monitors help you get alerted about elevated errors and failure rates. And this means that your agents are able to identify and investigate issues long before your users do.

Also, though, these advisors have historically sat within the dashboard, and we built this new agent skills to bring them directly inside your harness. So you can add the skill with one simple CLI command. And with these, the agents are able to autonomously monitor your database and your performance as well as your security. And combined with the MCP that I announced earlier and compute, your agents can even fix the identified problems on your behalf.

As agents have become more capable, we want to ensure that they only do good stuff with your database. So today we've added scoped access tokens. Previously we had personal access tokens, and these inherited all the permissions of the developer who created those tokens. With scoped PATs, you can restrict the token to a specific action, a specific project, or you can even set an expiry date inside the scoped PATs.

Additionally, we've introduced this new thing. Some of you won't have heard of this, but it's quite an important one, and I think it's going to be really important for the industry. It's called MCP elicitations.

So without elicitations, agents can basically do anything with your MCP, and they can cause a lot of disasters. I'm sure you've seen some of these online. And there's no certain mechanism to ensure that there's a human approval on some of these actions. So with this, we've just released Claude elicitations. So when the agent goes to either create a project, a branch, or to execute raw SQL on your database, you can give final human confirmation, and it protects you from rogue actions. We'll add a bunch more potential actions to elicitations. They're coming soon.

Okay, as your app grows, it's really important to move heavy analytical queries from your production database out to some sort of... or basically just out of your production database. So today we're launching Supabase Pipelines in public alpha. And with pipelines, you can move the data from Postgres to one of four stores today: either BigQuery, ClickHouse, Snowflake, or DuckLake, and we have more coming soon. The data is moved in real time. So as soon as you're updating it in your database, in your Postgres database, it becomes available in your data warehouse.

And to wrap up our lightning round, we'd like to share Supabase Evals. So new model releases are happening more than ever. There have been, I think, seven frontier model releases in the last month alone. You need to know which models work best with Supabase and all the features of Supabase. And this way, under supabase.com/evals, you know which model you can choose for the tasks.

Okay, that's all for the lightning round. So there's eight releases in five minutes. We're going to talk about a much, much denser topic, and we're going to talk about scale. Our goal at Supabase is to help you go from prototype to petabyte.

And I'm going to warn you, this one's going to be a little bit more dense. And I'm going to give you some background on databases. I'm going to go kind of medium density. And each one of these actually has a follow-on talk or several follow-on talks later today.

We're going to talk about scale in three different ways. So first is going to be performance. Then we're going to talk about scaling up to petabytes. And then we're going to talk about scaling out.

Starting with performance, let's talk about OrioDB. We started this thread last year at Select, and this is one that we've made enormous progress on in the last 12 months. So let's do a bit of background on how Postgres works under the hood.

Postgres has evolved a lot over the last 30 years, and every year there is a new major version with a ton of new features. But one part of Postgres actually hasn't changed pretty much at all, and that's the storage format. Postgres uses heap storage, and heap is great, but other databases have seen a lot more innovation in this space. So, for example, MySQL moved from MyISAM to InnoDB in 2010.

Heap storage has been really a great foundation for Postgres, but it has two major drawbacks. The first and the biggest one is something called dead rows. We call them dead tuples.

Postgres heap tables don't actually update rows in place. What happens is, with every update, it creates a new row version and then it leaves the old one behind. Once this is completed, the old versions become these dead tuples, and then they continue to occupy the Postgres space until Postgres has time to clean them up, and that process is called vacuum.

Anyone who's run vacuum in production knows how frustrating it can be. And if you don't know, basically vacuum competes with your queries, and it slows down your database.

On a database with really frequent updates, a single vacuum can run for days, which creates another really, really big problem. If vacuum falls far enough behind, then we get something called transaction wraparound.

Every write in Postgres is assigned a special transaction ID. In heap storage, this is 32 bits, and that's a little over four billion possible values. For a database that's doing a lot of updates, you can actually run out of transaction IDs. This has happened on the Supabase platform for some of our largest customers.

Vacuum helps to reclaim the transaction IDs from these dead tuples. But if the vacuum ends up falling behind, the database can simply run out of IDs. And when this happens, your database goes into read-only mode.

So yeah, this isn't theoretical. Some of the best engineering companies in the world have faced it. As I said, customers on our platform. It's happened at Century in 2015, Mailchimp in 2019. It's really a difficult challenge to solve, but we've fixed both of these problems thanks to OrioDB.

OrioDB is the same Postgres that you know and love. It's the same SQL, and it supports all the same extensions. In fact, OrioDB is just an extension itself that replaces the storage engine. It scales further, it's faster, and there are several other innovations, four innovations that I'll talk about today. And then Deepd is going to do a deep dive on this later on today.

First, vacuum. Heap requires it. OrioDB doesn't, because updates are made using an undo log. The second is wraparound, which I talked about. So heap uses those 32-bit IDs. Wraparound at 15,000 transactions per second, wraparound would happen in just three days. Orio uses 64-bit IDs. So at the same rate, it would take about 30 million years for wraparound to happen. So it just will never happen. Well, we'll see.

Okay, Orio makes huge improvements to the write-ahead log, which is used mostly for replication. Heap storage sends eight-kilobyte blocks no matter how big or small the update. So if you make a smaller update, then it's still going to send eight kilobytes. This is quite heavy. OrioDB uses row-level updates, much smaller, and it sends less data over the wire, and it means that you have less replication lag.

And finally, OrioDB makes major improvements to index management. With heap, indexes point to a physical location on disk. So when you make an update to a row, Postgres has to update all of the indexes. But with OrioDB, they point at the primary key. So it only updates indexes when the values actually get changed. Much better for your database.

So how does it perform on TPC-C, which is an industry standard benchmark? Orio runs two times faster than heap. This is a huge performance boost that requires no changes for your queries. A lot of work has gone into this, and you can find all the benchmarks at dbarena.com.

We're pretty proud of this because imagine if the Postgres community released a new major version and they said we have 15% better improvements or better performance on Postgres. That would be huge news. So we're really, really proud of the performance improvements that we're seeing in OrioDB.

But performance is not the only thing that matters for a database, and it's definitely not the only thing that we've been focusing on. So for the last few releases, we haven't just built this storage extension. We've built an entire testing harness for OrioDB. We use pg_regress to test full compatibility with Postgres. We run nightly TPC benchmarks to catch any performance regressions. We run it through a tool called Antithesis, which is an amazing tool, by the way. Go check it out. It can simulate years of production into just minutes of testing. And then we run it through Jepsen, which is an industry standard for ensuring database consistency.

And we're not just building this for the Supabase community. As with everything, we're building this for the Postgres ecosystem. OrioDB is 100% open source using the Apache 2 license. We've made all patterns freely available under the same license. For those of you building on Supabase, Orio is available today when you launch a new project.

Okay, so performance. Now let's talk about scale up. I know a lot of you want to hear a lot about this topic. It's a dense one. We've got a lot to cover. So it's covered across three talks today. First, let's do a bit of background.

Last year, we started work on Multigress. Here at Select, we announced that we were going to start that work with the goal to help Postgres scale through sharding and high availability. We looked into all the industry tools. We looked at things like Stolon and Patroni. And what we realized is that every single tool on the market had the potential to lose data under certain conditions, which is a big problem.

We realized that what we needed to do to solve sharding and to support Postgres at scale, we needed to build a fully holistic solution. We needed to start with connection pooling and routing. We needed to reimagine replicas and promotions. We needed durable backups and zero-downtime upgrades, and all of it needs to be wrapped in observability and transaction management. What we needed was Multigress, the operating system for Postgres.

So what is Multigress? Multigress is built from the ground up to be the world's most reliable and scalable Postgres operator. It has built-in connection pooling. It has HA, it's got backups, and of course, it's got our work towards sharding.

Let's talk about some of the problems. So the first one we really, really needed to solve is connection pooling. Many of you have used a connection pooler, and you know that with most connection poolers you need to choose different modes. For example, session mode or transaction mode, and each one of these comes with different trade-offs.

That means that you're constantly juggling the right mode for the right use case. But with Multigress, we've completely solved this. You have one connection string for every transaction type. You no longer have to choose a different mode. You just connect to your database.

Because Multigress is a fully integrated system, it brings some incredible advantages for working with replication. The gateway sends writes to your primary, and it sends reads to your replicas. But really importantly, it knows if a replica has fallen behind, and it can keep buffering the traffic until your replica catches up.

And of course, things don't always go to plan, and sometimes your primary can experience a problem. And if that happens, Multigress will notice immediately, and it responds.

First, Multigress will hold open all transactions that are happening in flight. Then it promotes a replica up to the primary, and then it completes all of those in-flight transactions directly against that primary. Finally, it starts a new replica to bring your cluster back to full strength.

And then we actually have tested this internally. We did a thousand sequential failovers, and we experienced no data loss through all one thousand failovers.

It was a very cool test. It was very cool. Yeah.

So far, this is about keeping one cluster healthy. But at some point, a single primary, whether it's healthy or not, becomes a really big constraint for the largest databases. That's why we're working towards the ultimate goal, which is sharding.

Sharding splits your data across multiple servers. For your application, it will still feel like a single database. There's no limit to the amount of data that a sharded database can actually store. But the hardest part of sharding, really the hardest part, and this is one of the things that Sugu said that he really wanted to focus on, and that is maintaining Postgres compatibility.

We're really in the early development stages of sharding, but we have designed Multigress so that when we get to that point, or when you get to that point, you won't have to change a single thing inside your database. You just continue doing the exact same queries that you use even on the smallest database.

Okay, there are a lot more features packed into Multigress, and we know you want to get your hands on it. And the good news is, again, like everything that we do at Supabase, this is all open source. So today we're releasing the full Multigress experience under the Apache 2 license.

That includes everything from the operator to the Multigress dashboard, and it can all be run independently of Supabase.

If you scan this QR code, or if you go to the link, it'll give you a prompt that you can put inside your favorite harness, and it will spin up an entire Multigress cluster on your laptop or your virtual machine. In fact, Johnny, when he was testing the slides forty thousand feet in the air, he scanned this on his phone on Claude Code, and he managed to launch the entire cluster directly on a VM running on Claude Code. So we're pretty confident it can run anywhere.

Don't do that in production, by the way.

So on the platform, we're already working with a collection of design partners. We're also working with selected customers for testing Multigress on the platform in invite-only. So if you want to be one of those customers, please reach out to us on that invite-only list.

We have a lot more to say on the topic, and we've got Sugu coming in two talks from now. Deepd as well coming to talk about databases, and then finally Manam will be talking later today specifically on the hairy details of connection pooling, which is a very, very interesting topic.

Okay, last one. This one's super interesting. So the world is changing a lot. We've covered scaling up. We've covered performance. We need to scale out where we're going in the world. I think Ant said we've kind of scaled to five million databases getting launched every single month. I am certain that in a couple of years we need to be launching billions of databases.

To do this, we really think Multigress is the right architecture for scaling up a single database. But scaling out to billions really requires a completely different architecture.

What you need is a database per user, one per agent, or even a database per idea. You need to be able to build without constraint. So today we're introducing our newest instance type, Supabase Spark.

Spark is built for billions. It has the same developer experience that you already know and love. To make Spark a reality, we actually had to rethink a lot of the architecture. There's kind of three principles that we had to design around to enable this type of architecture.

First, we need to think of the database as a file and not a machine. Second, it needs to be multi-tenant by design. And third, it needs to be built on object storage, which gives us eleven nines of durability at a very cheap price point.

Fortunately, there's already a leading database provider who has been building in the agentic space. They've been doing it for about five years now, and they're a company that we knew would be perfect for helping us to build Supabase Spark, which is why we're proud to announce that we've acquired Turso.

Spark will be powered by the Turso technology. We're adapting their scalable architecture to the Postgres DNA that Supabase already has. Turso will continue to focus on SQLite databases, as they already have for the last five years.

Again, we have a lot more to say on Turso than I can share in this session. So I've invited Global Costa, the CEO of Turso, and he'll join us on the build stage later today to talk about databases in the agentic era.

Okay, so that is the tour. We've done build, operate, and scale on Supabase, so you can go from prototype to petabyte. The day so far, we're just getting started.

Are we? How are we? Cool. Okay, we're just getting started. So later on today, we're going to have deep dives on Multigress and Turso. We're going to have firesides with OpenAI. We're going to have firesides with Anthropic. And as Ant mentioned, we're going to close out the day with one of the OG builders, who is Wes.

And so for now, it brings us to our first guest.

So this year, more than ever, the world has shipped more than we ever have before. There's more models, there are more agents, more tools. Things are moving faster than we can actually keep up with. And so nobody has thought more about how humans learn than the person who actually taught the world machine learning. So let's welcome the founder of Coursera and DeepLearning.AI to the stage, Andrew Ng.

Thanks everyone. Sure, let's go.

You know, I'm actually very excited about the future of databases. I know you're going to ask me another question. Just share one thing. I feel like right now the world is going through a massive data center buildout with a lot of AI training and inference data centers being built. I suspect something that a lot of the world does not yet appreciate is that in the future, a lot of core infrastructure, be it compute and storage, will be used not just by humans but by agents, and that agentic usage of all this infrastructure will drive massive demand.

So in addition to the AI data center buildup for training and inference, I think a lot of databases have been built for human usage to date, and we can only look at a query so much data. But with agentic usage, I think the demand for core infrastructure for compute will continue to skyrocket. So actually very bullish on this category as a whole.

Yeah, it's an amazing space. I mean, we feel very fortunate to be in the thick of it. And actually, we had a partner day yesterday where we invited a lot of people who work with builders or developers, and basically everyone's saying, yeah, we're running out of compute. We need... like the amount of builders pouring into the world is just going crazy right now.

Yeah. Yeah. Yeah. So actually, I'm going to start because you have one of the most impressive backgrounds, and I couldn't memorize it all. So I'm just going to... I know you're very humble. I'm going to read out for anyone who doesn't know: you're the founder of DeepLearning.AI. You're a general partner of AI Fund, managing partner of AI Aspire, chairman and co-founder of Coursera, professor at Stanford University. Previously, you were the founding lead of Google Brain, VP and chief scientist at Baidu, formerly director of the Stanford AI Lab, and you are part of the Time 100 AI list for the most influential AI persons in the world. So first of all, that's crazy. Thank you. Thank you.

What a life. Actually, how do you have the energy to kind of keep reinventing yourself and keep doing all these things?

Yeah, I feel like the answer I have is kind of the obvious one, which is I've been really so blessed to work with so many great people consistently across so many organizations. I feel like but for the people I get to work with, I would hardly manage to accomplish anything myself. So I've just been really blessed.

That's cool. That's cool. Okay. So I was going to talk about Skills Map. I was going to try to explain it, but you are first and foremost a teacher. So maybe you can tell us a little bit about Skills Map, what you're doing at the moment, and then we can dive deep.

Yeah. I think the most exciting profession to be that's very rapidly at this moment in time is AI engineering. And by that I don't mean people that'll take on an AI engineering job title, but rather people in all sorts of job roles, including software engineering, front end, back end, DevOps, mobile, that will benefit from having AI engineering skills.

So my team at DeepLearning.AI did a lot of work over several months to try to map out what are the skills that are needed to do AI engineering well. And so we wound up categorizing... So we looked at over ten thousand job descriptions, job postings, did dozens of structured interviews, ran a bunch of our own surveys, and synthesized views, talking to partners as well.

And we wound up figuring out that there are four key skills needed to do AI engineering well. One is the ability to build and deploy AI applications, and the difference between AI and non-AI applications is they're uncertain, and so how do you manage that? Second is software engineering fundamentals. It turns out that even with AI writing a lot of code for us, people that understand software engineering fundamentals, understand what's the write ratio, what's a transaction, you know, people can steer coding agents much better that way.

Third is the ability to use coding agents. And then lastly is the skill of shaping the build, because developers are no longer playing a role where someone tells them what to do and they just implement it, but instead are participating in deciding what to build and also influencing the process by which something gets built.

So what I'm seeing in the job market today is developers, either people with an AI engineering title or people with the other title that's gained some AI engineering skills, are in great demand, and we just can't find enough people with these skills. So DeepLearning.AI is excited to work upon this to help more people become skilled at AI engineering.

Cool. And the Skills Map itself... Actually, first of all, starting with skills, why are you focused on skills in particular? I think you have a view on skills that they're one of the more important parts. Do you think that they're going to be critical as we go along, or can the agents just become so good that we don't need to focus so much on providing our own custom skills? How do you see this part evolving?

Yeah. So, you know, I think about... there's some things we do today that I hope an agent will take over. For me, for example, you may remember three-ish years ago there was a lot of hype about the prompt engineering job and how much money someone could make by being a prompt engineer. And I think at that time it was already clear to... actually, I give Chris Manning credit for saying this very clearly even back then, which was this idea that we need humans to have arcane incantations to prompt an LLM to do something, that's going to go away because an LLM was going to learn how to make those same arcane incantations.

And so even today I see some things that, like, you know, how do you manage a swarm of agents? Some things humans would be needed to do. Some things is more of a one-size-fits-all that I think AI agents will manage other AI agents better and better in the coming years.

And one of the key things that distinguishes whether AI will take this over or not is whether or not humans have a fundamental context advantage. It turns out when all of us are building applications, we know a ton of stuff that AI agents do not know. You may remember a conversation with a customer, you know, where you said something and there was a funny expression on their face, or you may remember something that you learned, you know, five years ago reading some market report saying people want this and not that.

So I find that humans have a bewildering vast range of context and are remarkably good at pulling out this context and making key decisions. And so for that set of decisions where humans have a fundamental context advantage, until someday where I don't know, like slap a camera on us and monitor the facial expressions of everyone we talk to and have... that seems a very difficult path.

So I think there's a large set of the tasks where humans with a fundamental context advantage that we want humans to do for a long time. And then giving people the skills to do that valuable work to complement the wonderful work that coding agents are doing, that seems to be the path that we'll be on for a long time to come.

And this is why, I think you've probably seen with coding agents being the wonderful things they are, the number of job postings for software engineering is up because as software engineers and AI engineers become more productive, we want a lot more of them. And businesses, I know even my teams, we just can't seem to find enough skilled AI engineers, and I think this will continue.

Yeah. So let's dig into that. Let's imagine two developers who are two strong developers, but one gets better results than the other. What would the stronger developer be doing that the weaker one isn't doing today?

You know, this is a great question. And when we were mapping out the AI engineering skills map, that was one of the questions we repeatedly asked ourselves, which is we actually interviewed a lot of people, and one of the standard questions we asked them was: think of a great developer, think of a less good developer, what is it you know that a really great developer does compared to the less good ones?

And a lot of the answers were what we wound up distilling into the AI engineering skills map. And it's actually more than one thing, it's a lot of very different things. But just to give another example, the first of four key skills we highlighted was the ability to build and deploy AI applications.

And it turns out that the key differentiator for AI applications compared to traditional software applications is they're uncertain, right? Whether you prompt an LLM or train a supervised learning algorithm, you don't know in advance what outcome you get. And so skilled AI developers have come up with, or are familiar with, a set of techniques to monitor the performance of these systems, often in a statistical way, and to drive a disciplined error analysis and eval loop to make progress in a systematic way.

And so it was by asking questions like that and reflecting on our own experiences that we then tried to systematically map out the, not one or two, but frankly the very large number of gaps between skilled developers and novice-level developers. And we tried to distill that into what we call the AI engineering skills map to then try to work systematically to help people go from less skilled to expert level at all of these really valuable skills.

Is the skills map itself for anyone to use, mostly for software engineers, people with background? How should people think about the skills map itself?

Yeah, so we publish... DeepLearning.AI, we publish a weekly newsletter called The Batch. So for five weeks in a row, I wrote about nothing but the AI engineering skills map. And actually, I know other companies that are now looking to structure curricula around our AI engineering skills map, which is actually pretty cool.

But I feel like for individuals, it's a way to understand what being excellent... which many of you already are, but where you're already excellent and other places where you're not.

So let's dig into that. Let's imagine two developers who are two strong developers, but one gets better results than the other. What would the stronger developer be doing that the weaker one isn't doing today?

You know, this is a great question. And when we were mapping out the AI engineering skills map, that was one of the questions we repeatedly asked ourselves, which is we actually interviewed a lot of people, and one of the standard questions we asked them was: think of a great developer, think of a less good developer, what is it you know that a really great developer does compared to the less good ones?

And a lot of the answers were what we wound up distilling into the AI engineering skills map. And it's actually more than one thing, it's a lot of very different things. But just to give another example, the first of four key skills we highlighted was the ability to build and deploy AI applications.

And it turns out that the key differentiator for AI applications compared to traditional software applications is they're uncertain, right? Whether you prompt an LLM or train a supervised learning algorithm, you don't know in advance what outcome you get. And so skilled AI developers have come up with, or are familiar with, a set of techniques to monitor the performance of these systems, often in a statistical way, and to drive a disciplined error analysis and eval loop to make progress in a systematic way.

And so it was by asking questions like that and reflecting on our own experiences that we then tried to systematically map out the, not one or two, but frankly the very large number of gaps between skilled developers and novice-level developers. And we tried to distill that into what we call the AI engineering skills map to then try to work systematically to help people go from less skilled to expert level at all of these really valuable skills.

Is the skills map itself for anyone to use, mostly for software engineers, people with background? How should people think about the skills map itself?

Yeah, so we publish... DeepLearning.AI, we publish a weekly newsletter called The Batch. So for five weeks in a row, I wrote about nothing but the AI engineering skills map. And actually, I know other companies that are now looking to structure curricula around our AI engineering skills map, which is actually pretty cool.

But I feel like for individuals, it's a way to understand what being excellent... which many of you already are, but where you're already excellent and other places where you're not.

You want to become more excellent, and then one thing DeepLearning.AI is working hard on is to then create those paths for people to become skilled at AI engineering broadly. But I think the educational space, both DeepLearning.AI and other companies, still have work to do to help people develop clearer paths to become skilled broadly at all of these AI engineering skills.

Yeah. It's interesting actually, you know, I don't know. It's funny. I actually don't miss coding by hand.

And then, you know, you spend three hours on a problem and finally it clicks.

I find that for myself, there's so many projects to work on and I don't have time to work on. And even as our capabilities grew, certainly my personal ambitions grew maybe even faster than our capabilities. And so, yeah, it's a different type of vibe, right? I think starting a coding agent before you go to bed to see what it comes up with the next morning is a different way of getting into the zone, I guess, than, you know, debugging some weird JavaScript syntax. But I have to admit I seem to like the new vibe more than the old one.

You know, it's interesting. I feel like the hype is that AI advances so fast. Everything changes every three months. Of the AI engineering skills map, the one piece that does change the fastest is coding agents. And the way we code now is very different than three months ago, very different than six months ago. So the use of coding agents is changing very rapidly. But when you look at the other parts of the skills that I find really valuable, the way we build and deploy AI applications, there are a lot of fundamental knowledge about how to see these systems, how to deploy them, how to monitor them, how to update them. That is actually changing much slower than the PR hype says. Oh, one other funny thing, at least before Astra, I think Astra may have changed, I'm not sure. It turns out most AI systems, they're not very good data scientists and not very good AI engineers. You kind of ask it what should I do in a project, and for the most part, and frankly data science, right? I now don't do my data science work by hand, you know, no more coding up pandas, data frames, whatever. I was so used to it on the back end, but I now use AI agents to do a lot of my data science work for me. And then frankly, it just makes really weird decisions. It comes to really weird conclusions. I hope that frontier models will get better, but somehow there's a lot of understanding the fundamentals to make tradeoffs. And I see that a lot of engineering is making trade-offs, right? You know, I don't know, cost, latency, and speed, reliability. And the challenge is until you understand the fundamentals, you often don't even know what trade-offs exist to be made, which is why when someone vibe codes without understanding, very often the coding agent will make a bunch of tradeoffs that you didn't even know it made a trade-off and just bites you later. So I find that people that are good engineers that understand the fundamentals in many, many parts of the skills needed just make much better decisions. But I'm also encouraged at what's now possible to do, you know, when you vibe code without understanding. But I think really good engineers just do such vastly better work than, you know, inexperienced engineers.

Yeah. So as building has become easier, the bottleneck is less building but deciding what to build. And so previously there used to be a lot of, let's say, front-end engineers, but now front-end engineers with AI assistance can also do a lot more backend than was possible. I'm personally much stronger on back end than front end, but now, you know, frankly, I'm maybe like a bad front-end developer with AI assistance. But so a lot of developers have gone from a more narrow role to being a full stack developer. But then even beyond that, it turns out that if a developer builds something and needs to wait for a product manager to get customer feedback and then, you know, steer what's built next, that's much slower than the developer themselves has a little bit of product instinct, a little bit of product gut, can talk to a couple customers or users and get feedback and keep driving the process forward. So in development, what I'm seeing is a lot of people are expanding their roles from just implementation to deciding what to build. And it does not mean engineers should become product managers, but it does mean that engineers that can make some product decisions or more architecture decisions are much more productive than engineers that play the more narrow side of role from a few years ago. And so we call this shaping the build, where engineers that can influence product decisions, have some product guts, also help to think through the build process, like is this a good time to build an MVP or is it a good time to invest in building really robust architecture and thinking about scale, or is this a good time to go out to customers to get feedback, or is this a good time to do some research to better understand what back-end technology stack you should use. So developers can steer the building process and end up contributing much more to the overall company project.

Yeah, I think, yeah, it's a great question. The challenge to answering that question is that the answer is stage dependent and it depends a lot on, you know, what Jeff Bezos calls one-way door versus two-way doors. But directionally, in the early stages of a project, you know, frankly, whatever idea you have, right, type it into a coding agent, build it, see what you get. So you can do it in a safe way and don't leak sensitive data or, you know, just don't, so there's protection from bad outcomes. But I find that for a lot of projects, one of the challenges about AI engineering is the right decision is very stage dependent. I find that for early stage projects, solless, you can do it in a responsible, safe way. Okay, build a quick and dirty prototype, see what happens, throw it away, build a quick and dirty product, see what happens, and drive rapid learnings. And then there's also a time and place for thinking carefully about architecture, figure out what's your rewrite ratio, what the customer requirements, what is sensitive data, thinking through your security infrastructure, and then doing that. So one thing I've seen is I've known a lot of engineers that are really good at the zero to one startup phase. I've also known a lot of good engineers good at the mature systematic phase, but sometimes depending on the stage of project you're on, the skill and the speed and how to think about velocity versus protecting from downside risk shifts. And even the use of coding agents, you see a lot of people talk about how, oh, you should always plan it out, write a long spec, and there is a place for that. And then sometimes there's a place if you know you're going to go to bed in 20 minutes, just bang out some stuff, have a coding agent work for a few hours and see what you get the next morning. And I think that stage dependent answer has been very tricky for people to learn.

So it will change. So let me make two observations. So first, I'm going to say something obvious but maybe sound controversial, but chatbots are terrible for learning, right? I love LLMs, use them a lot, clearly pro-AI at the same time. On university campuses and in, you know, K-12, we know that students that use LLMs do better on homeworks but worse in final exams. And educators have known this intuitively, students have known this intuitively, but the rigorous studies are now increasingly coming out that show that cognitive offloading into an LLM, meaning if a student does an LLM think for you, you get more work done but you learn less. And I think even though the rigorous studies on this are coming out in K-12 and in higher education, university, in formal educational contexts, I think people still underestimate the degree to which this is happening among working adults. I find that, you know, I love my coding agents, helps me do a ton of work, but the reduced thinking I have to do. I think there are certain things that... And then to be clear, there are ways to use that do improve learning. Just like I think there are ways to use TikTok that's great for learning, but the vast majority of ways the vast majority of people use social media does not result in learning, and the vast majority of ways the vast majority of people use LLMs does not result in learning. So now the flip side of this though is I think we can do better. So the teams I work with, including Coursera, Udemy, DeepLearning.AI, Learn Vector, are working hard to create new learning experiences that are not focused on getting stuff done but rather on developing, rather on focusing on accelerating human development. Here in Silicon Valley, we're really excited about our frontier AI labs and accelerating AI development, and that's great. I'm very much in favor of that. In Learn Vector, which was a recently announced company funded by Coursera's initial investor, I'm actually really excited about not just accelerating AI development but accelerating human development. And the way that we're operating is building Learn Vector into a frontier AI, into a frontier human development lab. And as one example, I feel fortunate that Coursera participated in changing education 15 years or so ago. But today, looking back on that experience, which still works, it feels very much one-to-many where we create one course and everyone kind of takes the same or very similar course and it works. Nothing's wrong with that. But the technology now exists for us to create much more one-to-one experiences and it will be much better. So Learn Vector hasn't yet announced exactly what products we have, but I'm actually very optimistic from the internal prototypes we have and we will have more to share in months.

Oh, no. So, you know, in the case of AI engineering, DeepLearning.AI's focus is to help developers become skilled at AI engineering, or if you're already skilled, to become even more skilled. Working hard on even improving what DeepLearning.AI offers. But I actually find myself taking a lot of DeepLearning.AI courses myself to learn what are the frontier tools, kind of what's the latest in the voice stack or in generative UI or, you know, building local memory for agents. So I find that maybe as an insider, I see a lot of ways I wish DeepLearning.AI were even better. But I think that my own learning actually a lot of has been with DeepLearning.AI. I hope you all will find that helpful.

Yeah. I don't know. I think coding on the phone has been so wonderful, but also maybe, I don't know. Yeah.

I use text a lot more than voice for coding. You know, with the usual Macini.

Thank you so much. And just say, you know, of all the credentials you rattled off for me just now, the thing that's going through my mind, my one credential you didn't mention was I'm also a proud father of two children. So, and so, and so, and so the reason I need to dash is because I actually need to go pick them up from school.

How is everyone doing? Can you hear me? Yes. How's everyone doing? Enjoying the sun. The sun came out. Well, any Postgres fans here? Yeah. A few. Any Supabase fans? Yeah. So, today I'm going to talk about scaling Postgres on Supabase. Among the things Coppel announced today were two launches for databases: Oreo DB public beta and Multigress private alpha. Oreo DB is a pluggable storage engine for Postgres. You already heard that Multigress gives us high availability, connection pooling, data durability, and in the future, sharding. We've spent the last year working on these two things and I want to tell you where we are and where we are going next.

Look at that number. Somehow this number grew 5x since we made this slide. We have more than 10 million active databases on Supabase, and these are all Postgres databases. But I also want to talk about some of the other numbers that we see. Many of you are running in production, and there is a diversity of people and companies that run their business on Supabase, and these are not just tech companies. There are finance companies, universities, healthcare companies, all kinds of industries, and a lot of them have actually already reached terabyte scale.

But where did they start? Every one of them started small. Among the terabyte scale databases we have that started in the last two and a half years, 78% started under 100 megabytes, and most of them actually started around 70 megabytes. That's basically an empty database with a few tables in it. And they grow fast. Among these databases which are at least a year old, the typical large database grows 6x in one year. That's about 16% a month, compounding every single month. Many of you here work for startups. Many of you here are founders. You hope for it, but you don't plan. You don't always plan for it. Scale sometimes just happens. You ship something, it goes viral, and you suddenly find yourself operating infrastructure at a scale that you actually never designed for.

And when you get to this kind of scale, it can break Postgres in several different ways. Your queries get slower. You have to spend time optimizing them. At some point, you run out of optimizations that you can do at the application level or the query level. And then you have to start looking deeper. The storage engine doesn't scale to your needs. You scale up your CPU, but you don't get the expected gains. It just doesn't scale linearly. The database can no longer support the number of concurrent connections you need. So you say, okay, we are going to start some replicas and use them for read queries, and then you realize that you need high availability. The database going down even for minutes is not acceptable when you have users all over the world. And you say, okay, I've got a replica, I'm going to fail over to that if something goes wrong. Then something actually does go wrong and you fail over and you find that you've actually, you might have lost data. You might have gone back in time when you came back on this replica. And these are all actually hard problems to solve, and that's what we set out to solve.

So everything that I talked about can be categorized into two classes of problems: how do you get the most out of a single node, and how do you get multiple nodes to work together? So let's start with one node. You have one Postgres database, a single node, and maybe you have a table that looks like one of these: sessions, jobs, events, queues. These tables are all similar. They have something in common. What they have in common is that they get updated a lot more than they get new inserts. The same rows change over and over and over again. And with the Postgres heap storage engine, what happens is that every update leaves behind a dead row. You already heard this, but I'm going to repeat it. So these are the kinds of tables where bloat and vacuum cost you the most. And these are the kinds of tables that Oreo DB is perfect for.

So dead rows, vacuum, you don't want to have to vacuum. And what happens when you have these dead rows and you have to vacuum is not only that you may end up with the database going into read-only mode in an extreme case, but even on an ongoing basis, it actually hits your performance. Your database slows down if there is a lot of unused storage lying around. And when you get to that performance bottleneck and you say, "Okay, I'm going to run replicas to scale my reads because my primary is no longer able to keep up with the load," what happens is that you then start running into the inefficiencies that Postgres replication has. With Postgres replication, the first write after every checkpoint requires writing the whole block to the write-ahead log. You heard about write-ahead log already. You all know what it is. But when you have to write entire blocks to the write-ahead log, that leads to massive amounts of network traffic to replicas. So that's an additional problem in addition to the MVCC bloat that you have with the heap storage engine. The other thing is that primary key indexes can become their own storage hogs because they are stored separately from the data and there's no block compression, which means that flushing pages to disk actually results in high IO. So you have a CPU bottleneck because your query volume is going up, and now you have an IO bottleneck with your remediation, with whatever you did in order to deal with that higher query volume.

Oreo DB solves all of these problems. So the first thing is the MVCC bloat and vacuum. And the way Oreo solves that is that instead of updates being written as new rows in your table storage, they are written into the undo log. There are no dead rows piling up in your tables. And most of the time there is nothing for vacuum to clean up. Oreo's write-ahead log is row-level, not block-level. And what enables this is the copy-on-write checkpoints. So with the standard Postgres checkpoints, you do have to write the entire block, but with a copy-on-write checkpoint, you actually don't have to write the entire block to the write-ahead log. You can do row-level write-ahead logging. So this means that your IO for replication is significantly more efficient, and you can also eliminate the IO spikes that Postgres generates when it takes a checkpoint. Tables are index-organized, so the data lives in the primary key B-tree rather than in a different place, and table data is compressed with Zstd on the way to disk, so the same working set needs less IO. So we had performance issues, replication IO issues. Oreo solves all of these things. And the way it is done, everything above the storage layer is untouched. It's the same SQL, the same wire protocol, the extensions you already use. The only thing that changes is how the data is stored and how it's versioned.

We did some benchmarks, and we wanted to see how well does this actually work, right? And these benchmarks are from dbarrenena.com. The site is live. Everything is open. The benchmarks can be reproduced. We took the same Postgres, the same hardware. The only thing that changed was the storage engine. And you can see from these numbers that Oreo is ahead at every size. Whether you have two CPUs or 32 CPUs, you are going to get a boost in performance from Oreo. But also look at what happens as your CPUs go up. At two cores, Oreo is about a third faster. But at 32 cores, it's almost twice as fast. But there is another nuance to these numbers, which is when you go from two cores to 32 cores, that's a 16x increase in your CPU and in your cost. With heap storage, when you go from 2 to 32, 16x the cost, you only get 11x the throughput. Whereas with Oreo, you get almost 16, a linear scaling with your CPU. And this is what I was saying at the beginning, that you may add hardware in order to work your way out of performance issues, but you don't always get the performance you expect out of that additional hardware. And with Oreo, you can actually get that kind of performance.

So up to two times the price performance that you get with vanilla Postgres. This obviously depends on your workload. The benchmark we did is a specific workload. Everyone has a different type of workload. Your mileage will vary, but this is possible. Or to put it another way, the cost of running a particular workload could drop by almost half with Oreo versus the heap storage engine.

So we did all of this, but do these numbers even matter unless the engine is reliable? A storage engine that is wrong but fast is of no use to anyone. So before we were willing to ship this into beta, the team ran it through deterministic simulation testing using Antithesis and fuzz testing, and they found and fixed more than 90 issues. Some of them were concurrency bugs, some of them were crash recovery edge cases. These are the kinds of things that would only surface after millions of simulated executions. And once we did that, we have the test suites. The test suites run every day against committed code. And if there is a regression, we catch it right away. So we are not claiming that bugs don't happen. Bugs will always happen. But we built a system that catches them before our users experience them.

What's next for Oreo? Oreo beta is with Postgres 17. We are working on Postgres 18, which ships with async IO, and Oreo can take advantage of the async IO to deliver more performance boosts. We are also working on features improving the concurrency of page compression. We can do index deduplication and reduce the amount of storage that is used. We would like to add support for just engine indexes so that full-text search and geospatial queries get first-class support.

So I started here, scale breaks Postgres in different ways. We talked about the storage engine and how Oreo solves them. Let's move on to the next set of problems. These are to do with connections, availability, durability. I won't talk about connection management because you'll be hearing more about that later today. But let's talk about availability and durability.

Solving for these problems requires coordination between multiple nodes. What happens with standard Postgres is that you have replication, but you get neither high availability nor durability out of the box. You have to build it yourself. What do people do? They set up replicas. They manage them themselves. In theory, this gives you several things. You get an additional server that you can use to scale your reads. If the primary node goes down, you can detect it and fail over to a replica and keep your service going. In practice, none of this is out of the box. Either you build it yourself and you maintain it yourself with all of the cost of that, or you cobble it together using the tools that are available in the open-source ecosystem. And when you do something like this, it can actually introduce new problems. With a single server, you know that if it goes down and comes back, yes, you were down. You lost availability, but when it comes back, it comes back with the same data. You're pretty much guaranteed that whatever data was written to the server before it went down, it's going to come back. But when you fail over to a replica, especially when the replica is asynchronous, which is the default in Postgres, these guarantees no longer hold. The replica could have been lagging, which means that when your application starts running on the replica, you could effectively be going back in time. You also run the risk of data divergence on every failover because what can happen is that you fail over to a replica, you start writing to it, then your old server comes back and you have two versions of data that you can no longer reconcile.

Now you may be thinking, Postgres has synchronous replication that solves all of these problems, right? It does solve some of these problems, and a lot of teams run it. There is some of you would have heard of Patroni, which is a tool that a lot of people use to do high availability, and the core maintainer of Patroni did a talk a couple of years ago where he talked about all of the pitfalls of synchronous replication. On paper, it looks like synchronous replication actually solves everything for you. But in practice, it still has gaps where things fall through the cracks and you may still end up in a data divergence situation. In addition to that, what synchronous replication does is that the primary waits for a standby before it acknowledges a write. And this means that you pay for that wait on every single write. So you are actually going to take a hit on throughput as soon as you enable synchronous replication, and you are still missing the other pieces of the puzzle, which are what is the mechanism that detects failures? What is the mechanism that actually does the failover? You're still in the same boat of having to build it yourself or having to use some off-the-shelf open-source software and managing it yourself.

Enter Multigress. Multigress has been designed from the ground up to solve not just connection management issues but also to solve the availability, durability, and scalability issues. Our mission is to provide an operating system for Postgres. Everything works out of the box. It's all automatic. There is no need to set up replicas and configure them. Multigress does that for you. We had to do it. We had to learn how to configure replicas so that everything works properly. But we did it once and a thousand people or a million people can use it without doing it again. There is no need to build tooling to detect failures. There is no need to build tooling to do failovers. Multigress does that for you. There's no need to manually fail over to a replica. Multigress does that for you when you need it and only when you need it. And as part of this, we built a whole new innovative way of ensuring that when you do fail over, data is consistent across nodes, whether the nodes are dead or alive.

How does Multigress achieve this promise? And the way we do it is by using consensus. Some of you will be familiar with consensus algorithms like Paxos, Raft. We have implemented consensus so that a write only counts as committed once the cluster agrees that it's committed, not just the server that's taking the write. And nothing you were told was saved is ever lost. Zero data loss when we do a failover. And when a node fails, the cluster promotes a replica and you're serving again in under 30 seconds. There is no human in the loop. There is no failover script to run and there is no support ticket.

So let me recap what we are shipping in Multigress Alpha today. High availability, durability backed by consensus, automatic failover. There's no tooling to operate connection pooling. Multigress puts a better pooler on every node. You're going to hear more about this. What's next for Multigress? After alpha, we work towards GA where we will provide the ability to migrate an existing database into Multigress on Supabase. And beyond that, we are looking at scaling out sharding and cross-region support.

Petabyte scale is not one or the other. It's a combination. With Oreo DB, you can scale up. You can run the same node faster, which buys you time before you have to scale out. And when you have to scale out with Multigress, you can do it safely and eventually you can shard. In theory, you can shard indefinitely, but in practice, Oreo DB reduces the cost of that sharding because a more performant node means that you need fewer shards for the same workload. So from the prototype you started last weekend to a petabyte-scale system running entire businesses, Postgres on Supabase will get you there in a cost-effective way.

So it's still Postgres but better. You can opt into Oreo when you create a project. It's beta for everyone. Multigress is invitation only. Sign up for the waitlist and maybe we will get you into it. Once you use either of these, you shouldn't want to go back. Next up is a speaker who needs no introduction, but I'm going to attempt one anyway. So this is someone who co-created with us, which was sharding for MySQL, who came up with the idea for Multigress and has been working tirelessly to make that vision into reality. Please welcome Sugu on stage.

How's everyone doing? Doing good. Good. Okay. All right. I am the last speaker. After this you get to go eat lunch and I'm going to go free-form, change gears, you know, kind of conversational stuff. And I'm going to talk about kind of behind the scenes how we built Multigress, actually something deeper, more about why we are building Multigress the way we are building it. So I'll talk a little bit like the way I see Multigress is it's like kind of building a house. When you build a house, you don't build it room by room, like bedroom, kitchen. The right way to build a house is actually go and start with the foundation. You build the foundation, then you build the frames, and then eventually at the end the rooms come up. So what we've been up to in the last one year is we've been building this foundation. So the one thing about foundation is that you feel like nothing is happening, but it matters. It's the most important thing that you need to build, and that is what we've been extremely busy with. And the question, the question you would ask yourself, you know, I should address, you know, the elephant in the room, you know what I mean, pun intended, sharding, or rather, why didn't we do sharding first? For me, sharding is like building the second floor. Unless you have the right foundation, if you just build sharding, you may not end up, you know, where you may have to go and retrofit a large number of things later, and we didn't feel like we should be doing that. You know, like if you ask, like, you know, could you build sharding first, you know, I would say, you know, there are many ways you can feed a cat, or it's an old proverb adapted to 2026. Yes, yes, yes, you can do that, but I would rather not do it. No, I'd prefer to do it right. But actually, there's another reason why we didn't go for sharding. Like when I came into the Postgres world and looked at the ecosystem, I wasn't really happy with where things were. I didn't feel like, you know, even running a single Postgres node, I don't think the tooling was there yet. I don't think, I didn't think that things could be better is what I felt. And so we decided to fix those things because if those things are not fixed and you build sharding on top of that, it's not going to be very solid. So I'll cover, I'll actually, I'll go deeper into why we did these things. What are the kinds of things you obsessed about? Why it took us so long to build this so-called foundation and what is inside this foundation? Actually, what is inside this foundation? We only have these three things: connection pooling, high availability, and we give you the Supabase features. And why did it take us an entire year to do this? As a matter of fact, you know, I would say, you know, the team that worked on this is top of the line. Some of the best people that could ever work on this problem. Actually, some of them, I think I heard, I saw them sneak into this room. If some of you stand up, the VITA team, the VITA/M team. Oh, there's a group there. Woo! There. And actually, Deepi should stand up too. She actually wrote the original high availability code before other people took over. So I will talk about why it took us this long. And the other question is why would you rebuild connection pooler? There's already connection poolers out there. There's already things that solve high availability, but they don't solve it like I wanted them to be solved, honestly. So I will talk about what is different about how we are solving it, and we'll go into that. Actually, before we go into that, I will quickly cover, this is the only architecture slide that I'm going to show you, the only technical slide. So this is what kind of what Multigress looks like. Your application is at the top, and it connects to, through a load balancer, to these gateways. As far as your application is concerned, you've connected to Postgres. This entire complexity that you have behind it, your application doesn't care about. It should look like Postgres for you. You just send it queries, and the queries are responded to. All these things underneath make sure that your queries are answered correctly and they are answered all the time. That's why we call it high availability. So something this complex is needed underneath. No, you cannot just connect to Postgres and get all these features because they won't scale or they won't stay up. But with this type of structure underneath, you can continue to scale forever. So that's the reason why we built this architecture. So what is the significance of this architecture? What do the gateways do? The gateways do two things. One is they accept an immense amount of incoming connections. Like you can have, you can bring in like a hundred thousand connections can come in, no problem, gateways can handle it. But if you directly connect it to Postgres, it'll just fall apart. So that's the part of gateway. The other thing that the gateway does is route the connection to the right place. For example, I want to, this is a full cluster with primaries and replicas. Say I want to do a primary query, it knows where the primary is and will send it there. If there's a replica that has to serve the query, it'll load balance between the replicas that are available. And the poolers, there's one pooler per Postgres, that is the one that handles your connection pool. It may feel like this is expensive in the beginning, why, you know, a gateway and then there's a pooler. The reason why you need this is because this is the only way you solve the high availability problem. For example, if a Postgres fails, you have to immediately fail over to another Postgres, and your application should not be affected. So that's where the gateway comes in and says, oh, the primary has changed, let me now start sending traffic somewhere else. So that is the reason why we have this architecture, and underneath there is the consensus system that makes sure that the primary is always available. As soon as it notices that a primary has gone down, it'll immediately promote another replica and make sure that your traffic resumes. Cool. So this is the architecture. I may go back and talk about this. I'll try avoiding because I don't want to go too technical. But the bottom line is for you, the most important property that you want from this is on day one you started off, you connected to Postgres. On day one thousand, it should continue to feel like the original Postgres that you connected to. So that is the goal of what we are building. It sounds very simple. It's beautiful. But it's very, very, very hard to do that, especially when you're at petabyte scale. And our goal is to make that happen.

Let's talk about the connection pooler. So every one of these topics, I'll talk about what we obsessed about. In the connection pooler, we obsessed about one thing. Most importantly, the one thing that we obsessed about is compatibility. It should not behave any different from you being directly connected to Postgres. How hard is this problem? Postgres has tried to do this multiple times, has given up. The Postgres developers, they've given up. They said it's impossible to do this, or they didn't say it's impossible. They said it's not worth it. That is not an answer I like. So I thought we are going to take this on and we are going to solve it. And the other thing, the other secondary important thing that we wanted to keep in mind is we should not give up performance for the sake of compatibility. So there's a balance there, and I'll talk about how hard that balance is. You know this, you all of you know that the state of the art, PGbouncer is the state of the art today, you know. And for me, I'm going to criticize PGbouncer like it is my own. And the reason why I take that liberty is if today I came to Postgres and PGbouncer did not exist, PGbouncer is what I would have built exactly the way it is today, right? But then I like to criticize my own work, and I want to say that, you know, PGbouncer has some shortcomings, and it is not a good long-term solution, especially if you want to go to really, really massive scale. Not, there are not many Postgres systems that have reached that massive scale, but I want to get there. If I want to get there, then we need to move past PGbouncer. There are some things that are problematic with PGbouncer. The big one is this transaction mode versus session mode. In transaction mode, you can do transactions efficiently, they will scale, but a large amount of Postgres functionality you can't use. In session mode, you can use the full Postgres functionality, but the problem is you get a dedicated connection essentially. You don't get a pooler. It's as if you are bypassing the connection pooler, which means that you cannot use too many connections. So if you're using PGbouncer, you have to choose between the two. And people that have no option, that have to scale, this is the best tool out there, so they have used it. But the biggest bummer, you know, in PGbouncer is if you use transaction mode and you send it something that should not be sent, like, you know, you create a temp table, it will send that query through, the temp table will be created on that connection. The next time you send another query, it'll give you another connection, and your temp table is unreachable. This actually is a very dangerous behavior because you may, the thing is, what PGbouncer says is your connection should not, your requests should not taint your connection, and it is your responsibility to do it, which means that you have to know what is allowed and what is not allowed. PGbouncer won't tell you that this is not allowed, so you may do something in the connection and then move away. That connection has gone tainted. Somebody else gets that connection, and they get a behavior where that you don't like. So it puts a lot of responsibility on you, the application developer. And today with LLMs going wild with their queries and stuff, this is not a very good place to be. So we decided, okay, we are going to fix this. So why does PGbouncer not vet your query? Why does it allow everything too? Is because it doesn't understand the queries you're sending. Now, Postgres is a very vast language, and it has some crazy constructs, and being able to understand what you're trying to do with a connection is near impossible. Well, near impossible. So we decided we are going to solve it. How do we solve it? Is we are going to build a parser, the entire Postgres parser. So three hundred thousand lines later, we now have a full parser. And we said, "Oh, we have arrived." You know, it's all going to work. But it turns out it is just the tip of the iceberg because there are all kinds of behaviors that are beyond just the construct. You know, you look at the construct, you did this, but then you cannot really predict what Postgres will do with that construct, right? So then we had to go iterate and then go further. But we said we are not cutting any corners. We are going to go all the way with this, right? So we had to fix prepared statements. Like there are a hundred thousand connections coming in, and there are only like, you know, a thousand connections to Postgres or so. Each of them is going to prepare a statement, and each of them is going to cause an additional prepared statement on Postgres, which is going to multiply its overheads. So we had to figure out a way to reuse them. And actually, PGbouncer does support prepared statements, but only at the protocol level. But if you type in a prepare, that won't work because, you know, it has to be parsed. So we handle that also. And query cancellation is another one. Like when your application connects to Postgres, it gives you something called, gives you back something called a process ID or a PID, we call them short form. And the PID you are supposed to remember it because what you do with the PID is if you send a query and suddenly it's taking too long, you need to kill it. You make a new connection and tell Postgres, you know, kill this query, whichever query is running on this PID. But that is actually a Postgres process ID. If you have a hundred thousand connections, how do you assign unique PIDs to each of them? And your PID underneath Postgres is continuously rotating because each time you are getting a different connection. So that's not a, it's a non-trivial problem to solve. I'm not going to talk about it because Man will cover it today on the build stage. So if you're interested, go and listen to him. And the other problem is some of the session variables, like when set a equal to a certain value.

All right everybody, hey, I'm Craig. Thanks, Sugu. I'm going to be MCing this afternoon. But I just have a quick couple of housekeeping notes before lunch. First of all, there are a bunch of bathrooms right here just behind the tent. I heard there was a line in there earlier. There's lots of great food available for you, including the Data Stack Snack Shack, brought to you by PostHog. And there are also halal and kosher options available at the kebab trolley. So yeah, see you back here at 1:30. Thanks.

One and done. Thank you.

Thank you.

Heat.

Heat.

Number

nine.

Heat. Heat.

Heat. Heat.

Heat. Heat. N.

Heat.

Heat.

Heat. Heat.

Heat. Heat.

Heat. Heat.

Hey. Hey. Hey.

Yeah.

Hey, hey, hey.

Heat. Heat. Heat. N.

Heat. Heat. N.

Hey,

hey, hey. Heat. Hey, Heat.

Hey,

hey, hey.

Yeah. Heat.

Heat. Hey, heat. Hey, heat.

Heat. Heat.

Hey.

Fun enough. I'm going to fake it till I make it so I get a rush. I'm going to dance, dance, dance and party all night because I want adventure. I don't want to be shy. Come on, let's be dramatic because I see why we're at it. I got big dreams, baby. I don't want to be static. I'm on top of the world, shining bright like the sun. I'm bigger than anyone. I want to be wild and forget the day. I want to chase the sky. I want a big car to drive me away. I want you to catch the sun. I want fun.

I want fun.

I want fun.

I want

play my game. Let me show you the way. If you follow me, baby, I'm going to shake up your day. It's time to be wild. It's time to be big. It's time to let loose and get your big kick. Let's be dramatic. See why we're at it. I got big dreams, baby. I don't want to be static. I'm on top of the world, shining bright like the sun. I'm bigger than anyone. I want to be wild and forget the day. I want to chase the sky. I want a big car to drive me away. I want to catch the sun. I want fun.

I want fun.

I want to find

I want to

I want to find

I want to find

I want by

I

Heat.

Hey, Heat.

Heat. Heat.

Down.

Yeah.

Heat. Heat.

We're young, lost, and faithless.

We act like we're unafraid.

And we've learned to live in fear.

And you're the escape I need. I always see you in color

in a landscape of black and white. I'll be your in mind. You're the hole that I go down.

The rush I'm feeling. God loves the rush I'm needing. I'll do anything to keep you beside me. You're the only hand I need to provide.

You're my perfect animal.

You play with my mood so well.

Without you, I get so low.

Your highs aren't so possible.

We keep breaking boundaries.

You broke down my BP.

Our blood streams are coming

to bring back our childhood dreams.

The rush I'm feeling. Your love's the rush I'm needing. I'll do anything to keep you beside me. You're the only hand I need to

love the rush I'm feeling. Your love's the rush I'm needing. I'll do anything to keep you stop. You're the only I need to revive me.

Heat. Blue

Green.

Oops.

Heat. Heat.

Hey,

hey, hey.

Heat. Heat.

Mhm. Swag

swag

swag.

Let me tell you about this city at the south of the map where Chev

but I got this shorty on my line and she calling me back. Okay, I ride down 45 with this dime on my side. All she want is a P. Okay, she feeling the V and I slide on 5%. So watch out for five. I swing lanes girl with both eyes closed. I might pull something dirty. Don't you ask me though. I might pull a wooden grain something unal

game. I'm just passing out something dirty. Don't you ask me though. I might pull a wood grain something unnatural just as quick as you going to get it. That's as fast as it goes.

Hold up. Got this drink in my cup. Got these at my showing love. I said man this chick at the club trying to hop on the wave. Got them doing double dutch for real.

Just any Michael Jackson.

I get you whatever you asking. Babe, I know you want to be tricked on you like that. And he left the city coming right. I might something dirty. Don't you ask me though. I might pull a wood grain something unnatural.

Just as quick as you get as fast as it go.

I'm just pass something dirty. Don't you ask me though. I might pull a wood grain. Something unnatural.

Just as quick as you going fast as fast as it go

game. I'm just passing up.

Oh,

hey.

Hey,

hey, hey.

Number

n.

Hey.

Heat. Heat.

Heat. Heat. N.

Hey,

hey, hey.

Heat. Heat.

Heat. Heat. N.

Heat. Hey. Hey. Hey.

for the win. Watch it. Push it to your heart. Push it to the limit.

High.

Try 100 times because we don't quite all the sound waves. Turn it out loud. My friends,

one 1 2 3

push to the limit. Internet. Sing it from the roof. Let the vibe transmitter. Everybody go be real transmitters for the win. Watch us. Push it. Push it hard. Push it to the limit.

High.

Try 100 times. We won't quit.

It's a potion.

Let the sound waves

out loud. I trans

love the vibe transmitted.

You make me feel so alive.

You make me feel so

You make me feel alive.

Every night,

You make me feel so good.

You make me feel so

You make me feel so

You make me feel so sad.

Every

time I launch

Heat.

Hey, Heat.

Heat. Heat. N.

Heat.

Heat.

Heat. Heat. N.

I got my reasons. I'm an expert in the party. I'm a diva energy. Oh yeah. You me when I step in the room. They want to turn the music up. Get

there's no stopping me. There's no stopping me. Ain't no stopping us now. My face in the crowd. I'm all dancing. Give myself the ground. Give it all I was in my heart. I show up when I want to. I'm show it off. I hit this until I drunk. I know exactly what I want. Yeah, that's me. Just know that I'm about to show it. Show it off.

I got my reasons. I'm an expert in the party. I'm a diva energy up

when I step in the room. They want to turn the music up.

There's no stopping me. There's no stopping me

now.

I'm

off the ground. Give it all in my heart. I show love when I want to. I'm show it all. I hit this until I drop. I know exactly what I want. Yeah, that's me. Just know that I'm about to show it. Show it.

Show it.

Show it. Show it.

I hit the spot until I drop. I know exactly what I want. Yeah, that's me. Just know that I'm about to show it. Show it off.

Show it.

Show it. Show it.

Hey,

hey, hey.

Hey, hey, hey.

around

you.

I think you know

Heat. Heat.

Heat. Heat.

I feel

like we Heat. Heat. N.

around.

Hey

Where you?

There's never been a better time to try to hit the finish line. Beast mode, baby. Get it done. Everything. Yeah. You could do it like this. 1 2 3 then cross it off the list. The clock ticking and I ain't about to miss. Listen to this right now. A gift. Yeah. Can't get your time back. Go do it right now. Don't wait.

You still got time yet. So do it right now. Got to be on your way. I got the will. I got the right. I'm on it. I got the drive. I got the fight. I've done it. Get up. Get loud. Right here, right now. Show you the way. Show you the ropes. You got it. Making your way. Making it known. You done it. Get up. Get loud. Right here, right now. Right now. Picture perfect when you get it right. Do it once so you don't see it twice. Feel amazing when you live right. At the end of the day, I'mma do it my way. Mama always had the good advice. Listen closely because she's so wise. I broke her down. Now, let me get it right here, right now.

Do it right now.

You still got time yet. So do it right now. Got to be on your way. On the way.

I got the will. I got the right. I'm on it. I got the drive. I got the fight. I've done it. Get up. Get loud right here, right now. Show you the way. Show you the ropes. You got it. Making your way. Making it known. You done it. Get up. Get loud right here. Right now. Rip it up. Go nuts. Everything we do, we have fun. Give it up. So what? Made it to the top. Didn't need no crush. This is the moment. Ready and go.

We already on it. I got the will. I got the right. I'm on it. I got the drive. I got the fight. I've done it. Get up. Get loud. Right here, right now. Show you the way. Show you the road. You got it. Fig way. Making it known. You done it. Get up. Get loud. Right here, right now.

Do it right now.

You still got time. So do it right now. Better be on your way. On your way.

I know

right now.

Mhm.

I feel it coming. I see it going.

Take me higher.

Take me higher. I feel they coming. Come on and show it. Take me higher.

Take me higher.

Heat. Heat.

I feel they coming. I see it going.

Take me higher.

Take me higher. I feel it coming. Come on and show me. Take me higher.

Take me higher. Sh every night I wanted to

take me higher.

Take me higher. Show every time I want it to

take me higher.

Take me higher.

Heat.

Heat.

Heat. Heat.

Heat. Heat. N.

Heat.

Heat.

Heat. Heat. N.

Heat.

Heat.

Yeah.

Yeah.

Heat. Heat.

Number

feel.

Heat. Heat. N.

Hey,

heat. Hey.

Heat. Heat. N.

Heat.

Heat.

Heat. Heat.

Heat.

Heat.

Heat. Heat. N.

Heat. Heat. N.

Heat. Heat.

Heat. Heat. N.

Heat. Heat.

birthday.

Hey. Hey. Hey.

Heat. Heat.

Heat. Heat.

Heat.

Heat.

Heat. Heat.

Heat.

Heat. Heat.

Fun, fun, fun. No, it's never enough. I'm going to fake it till I make it so I get a rush. I'm going to dance, dance, dance and party all night because I want adventure. I don't want to be shy. Come on, let's be dramatic because I see why we're at it. I got big dreams, baby. I don't want to be static. I'm on top of the world, shining bright like the sun. I'm bigger than anyone.

I want to be wild and forget the day. I want to chase the sky. I want a big car to drive me away. I want to catch the sun. I want

I

play my game. Let me show you the way. If you follow me, baby, I'm going to shake up your day. It's time to be wild. It's time to be big. It's time to let loose and get your big kick. Let's be dramatic. Cause a scene while we're at it. I got big dreams, baby. I don't want to be static. I'm on top of the world, shining bright like the sun. I'm bigger than anyone.

I want to be wild and forget the day. I want to chase the sky. I want a big car to drive me away. I want you to catch the sun. I want fun.

I want

I want

I want to find my

I want to find

I want to find my

I

Heat.

Hey, Heat.

Heat. Heat.

Heat. Heat. N.

Heat. Heat.

We're young, lost, and faithless.

We act like we're unafraid.

And we've learned to live in fear.

When you're the escape I need. I always see you in color

in a landscape of black and white.

I'll be your last man.

You're the hole that I go down.

The rush I'm feeling. God loves the rush I'm needing. I'll do anything to keep you beside me. You're the only hand I need to rule.

You're my perfect animal.

You play with my mood so well.

Without you, I get so low.

Your highs aren't so possible.

We keep breaking boundaries.

You broke down my BP.

Our blood streams are coming

to bring back our childhood dreams.

The rush I'm feeling. God loves the rush I'm needing. I'll do anything to keep you beside me. You're the only I need to

love the rush I'm feeling. Your love's the rush I'm needing. I'll do anything to keep you stopping. You're the only I need to revive me.

Heat.

Heat. Heat.

Hey.

feel

down feel

down.

Heat. Heat. N.

Heat. Heat. N.

Heat. Hey, Heat.

Hey,

down.

Heat. Heat.

Swag,

swag, swag, swag,

swag,

baby.

Let me tell you about this city at the south of the map where Chevy

on my line and she calling me babe. Okay, I ride down 45 with this dime on my side. All she want is a P. Okay. She feeling the V and I slide on 5%. So watch out for 5. Told her I swing lanes. Girl with both eyes closed. See I might pull something dirty. Don't you ask me though. I might pull a wood grain something unnatural

just as quick as

fast as it go.

I'm just pass something dirty. Don't you ask me though. I might pull a wood grain something unnatural.

Just as quick as you going fast as fast as it goes

up. Got this drink in my cup. Got these at my shows and they showing me love. I said hold up this chick at the club trying to hop on the wave. Got them doing double duty

and Michael Jackson.

I get you whatever you asking. Babe, I know you want to be tricked on you like that. And he left the city coming right. I might pull something dirty. Don't you ask me though. I might pull a wood grain, something unnatural.

Just as quick as you get it as fast as it go.

I'm just pass something dirty. Don't you ask me though. I might pull a wood grain. Something unnatural

just as quick as you won't get it. As fast as it go

game, I'm just passing up.

Hello.

Hey. Hey.

Down.

Oh yeah.

Heat. Heat.

Heat.

Heat.

Heat. Heat.

Heat. Heat.

Heat. Heat.

for the limit.

Push it to your heart. Push it to the limit

high.

Try 100 times. Because we won't critic on life. It's a potion. We fus the sound waves. Turn it out loud by transmitting.

1 1 2 3 pivot push to the limit. We sing it from the roof. Let the vibe transmitter everybody go be real transmitters for the watch.

Push it hard. Push it to the limit

high.

Try 100 times because we won't quit high on life. It's a potion.

We fuse like the sound waves. Turn it out loud. Transmitted.

Turn it out loud. Let the transmitted

You're making me alive.

You're making me so

You're making me so alive.

You make me feel so

every

You make me feel so good.

You make me feel so

You make me feel so

make

Heat. Heat.

Every

Heat. Heat.

Hello. Hey everybody. Welcome back. Round of applause for everyone showing up today. Yeah, thank you.

All right, we have a really packed afternoon. It should be super fun. So, welcome to the stage, Ant Wilson, co-founder and CTO of Supabase, Dalton Caldwell, partner emeritus at YC and co-founder in GPS Standard Capital. Round of applause, and Michael Seibel, co-founder of Twitch and partner emeritus at YC. Thanks everybody.

All right,

welcome guys.

Thanks for having us.

So I'm sure you guys all know who these guys are already, but just by way of very quick introduction. Michael and Dalton were both YC partners when Supabase was in YC. Both serial entrepreneurs. They've been there and done it like multiple times each successfully and now both serve on a bunch of boards. And Dalton runs Standard Capital, which is like — is a fair way to describe it — like it's like YC for Series A.

I think that's fair. Yes, nailed it. Great.

And despite working together since 2020, this is like the second time we've seen each other in person. Basically, the last time I saw Ant was in an elevator

in San Francisco and you're like this week.

Co batch. Co batch.

Yeah. Which actually like brings me right onto the first question straight into the spice, which is like, do you need to be in the Bay Area to start a successful company?

So I think the answer is yes. I don't know how Supabase has figured this out. I will say that

Supabase — you got to say it right. I think that like I'm always impressed when companies succeed because we work with so many startups and there's so many kind of rules on what makes a company successful, but then inevitably when you look at a successful company they break some rules, they follow some rules, and so it's easy to say, hey, you should be here. There are obvious examples of success when you're not. But then like if I'm trying to be a little bit more honest, I would basically say you should try trying to figure out how to take things from this place. Like this is a special place for startups. And like if you're finding no way to get value out of this place, you're probably doing it wrong. Live here or not.

Yeah. Yeah. I think look, if you're sitting here and you already live here, good job. But if you came in for this, you're following Michael's advice, which is you were smart enough to come to this event and meet people. No, seriously. This is a great way to get access and some of the juice even if you don't live here full-time. And so I would encourage folks to be deliberate and thoughtful of how to get the most out of the ecosystem in the Bay Area. We were just speaking about this backstage where even you all have to come here for fundraising. And so you know, no matter what you do, try to make the most out of this particular network. And to the extent you know people here, it's very helpful.

Yeah. Yeah, definitely. And you know, the other benefit I see is like meeting your co-founder. I do think me and Koppel got kind of lucky that we met together in Singapore. We got introduced by a mutual friend.

But on the topic of co-founders, now there's tons and tons of Supabase customers, Supabase users, people using all of the AI tools, who might be non-technical, and they ask us the question all the time, is like, Claude Code is now my CTO. Is that enough? Have you got any opinions?

This is some of our least popular advice and we're just going to keep giving it, so sorry. Basically, you probably should have a co-founder. And we even made a video about this recently, and I guess there's a lot of comments, and the comments were like, I don't need a co-founder, like you know, I built this thing, you know, it works. So to underline the point, the biggest value of a co-founder is not that you can't build a product as a single founder. Of course you can with the quality of coding models now and with Supabase. Of course you can. But the emotional support and the value of having someone to talk to and to bounce ideas off of and actually put in the time and effort to build a company — that's our strong argument about why you need a co-founder. And for the folks — even for the folks that do succeed without a co-founder, they have someone in that role of emotional support person to talk to them all the time. Even if they don't give that person the title co-founder, everybody's got to have something like that.

I think there's a misconception about the amount of work involved in getting from zero product to some product, some product to where y'all are, and then where you want to go. And I think that it's really hard for us to argue nowadays that you need somebody to go from no product to a product. And that's actually kind of amazing because when we were growing up, that was a requirement. But I think that, you know, working with thousands of YC companies, it's just so hard to explain how that's so early. Like, you know, your first MVP is like the first swing of your bat in the first game of a baseball season. It's so early. And you just got to think a little further out than that and kind of think what would you want if you're really trying to get to the end of the season. Maybe you're trying to get to the postseason. Maybe you even want to win the World Series. What would you want in that case versus what's the minimum you need at this exact moment to get one step forward? And that's where I would give advice.

So to frame this for Supabase, if you all are here in the audience, you're probably like, wow, Supabase made it. They're on easy street. Like this guy's up here and they just raised a — they're at a 10 billion valuation. Life must be easy, right?

Tell us about easy street.

But the truth is, and I really mean this, these guys are still in the first inning.

And it's so awesome that they have this powerful co-founder relationship. And you need a rock. You need someone to go through the stuff with because it doesn't actually get easier. And that, you know, you have to kind of keep fighting every day. Even if you're throwing conferences and you're on stage, this stuff's still hard, right, man? And so I'm glad you have a co-founder, I guess, is the advice.

Yeah. Yeah. And actually, my experience and Koppel's experience is exactly that. It's like you both have the hard periods where you need the other person to then like grab the flag and be the one to drive it forward while you have your like couple of weeks of like being an absolute panic. And then you exchange places again and the other person drives it forward. So I definitely agree with that. But so I can't use like a Grok bot as my emotional support is what you're saying.

I mean, you go. I don't know. I think the jury's out. How about that?

I was going to make a LWD comment, but I won't.

Yeah. Don't do it, Michael. Don't take the bait, Michael.

No. Great. And Michael, you mentioned that now people can get an MVP stage using like a lot of the great tools that are available. Is that enough nowadays to just go out with an MVP and start showing people, or now that I can take it a lot further with these great tools? Like should I be making sure it's rock solid before I show it to people?

So this is a question where I don't know if Walton and I agree. We'll see. Yes, it is enough. In the last 18 months I've done this jaunt into the non-technical world, the world of government, and you might be surprised at how — I don't want to say the word behind that sounds bad, but how excited they are to have software that feels like it's built for them versus their workflows have to be shoved into something that Microsoft made. And you kind of take a step back and you realize how many people hate the software they use every day. Like that describes most of humanity. And so I'd argue that your ability to build an MVP quickly means that you can be one, inspiring your users, showing them what's possible, learning from them. All of those things are really, really important. So I would never tell someone like wait for all these other things before you get an MVP and start talking to users. I would always just say, but in parallel, what are the other things you need if your goal is to actually make a company that really solves their problems over time at scale. But it's been exciting to build. I mean, the amount that I've built — I am a poli-sci major — is incredible and it certainly blows away people who've never made software before.

I feel like there's two angles here. Number one, with technology, you're always in an arms race, and as tools get better, your competition gets better. And so, yeah, if you had a time machine and you could take the current tools to 15 years ago, you're going to clean up. You're going to beat everybody if you had, you know, modern coding tools. So the problem is a lot of you that are building things have other people just like you building things, and the market is very crowded. So that's a problem. On the flip side, there's this funny cognitive bias that I felt a long time ago and I know people do now, which is that all the good ideas are taken. And it sure seems like in the 2000s when we were founders that all the good ideas were taken, didn't it? It did. And so I can imagine many of you feel like all the good ideas were taken. I wish I had — I was a founder 10 years ago. And I guess I'm just trying to say it always feels that way. And that's just the nature of trying to create new products. And so what's the takeaway? I don't know. You got to come up with ideas that aren't obvious to all the people just like you. Because that's what worked in the past, right? Like Supabase, was that a new idea at the time? Like right, like how did you — did you feel like all the ideas were taken when you started the company?

No. And actually ours was quite funny because often when you start a company the first question investors ask you is, okay, but what if Google does this? And like Google were already doing it, and it's what led us to — is this gone off.

It's what led us to compete with

compete with — Okay, we've lost everything.

I think we lost all the mics.

All right,

let's go organic.

Yeah,

we can yell.

So

yeah, we lost them all.

It's all right. We'll crack on. We basically were competing with Google from day one. And it turns out that like

Google

Firebase was competing with all of the other Google databases internally so much that they just — there was all these gaps. And whether it was like you didn't have the ability to set like pricing caps, whether it was it's a completely proprietary system and not open source. Like there's lots of angles we could take to

to compete. Oh, for the stream. Okay. Okay.

Okay. So, so

we talked about MVPs, but what about like gathering user feedback? There's all these amazing agentic tools now that will do that for me, right? Like I can have an army of Grok bots. They go and solicit user feedback. Like, do I still need to go out and

I mean, I haven't tried — I haven't actually tried to prompt my agent to build a billion-dollar company for me while I am on the beach. So I can't confirm it doesn't work. I might try when I leave here. I think that — I think the biggest misconception that I had when I started advising companies was what's the purpose of the first two years of a company? I think there's this narrative that the purpose of the first two years is to like invent the thing that blows up and then like have glory. I think often the purpose of the first two years is to figure out what the going on like at all. And so it's literally like, you know, whatever idea you had usually doesn't survive that first two years completely intact. And I just see the volume of learning about the customer, about the space, about the competition. When I talk to founders a year in, they're like, if I knew what I knew now, I would have never started this company. I was so dumb about everything in this whole space. I was completely lying to myself. And that's how everyone feels. And so I think sometimes founders have this expectation that like, oh, I'm executing on this incredible strategy and getting to victory from day one. And like my expectation is you're making mistakes. You're going to have to do things over again. All you're doing is learning and skilling up. Why would you want to outsource that?

Like that — that can be your competitive advantage. So I think there's this weird almost like what can I — I don't want to say the word outsource, but like how can I do it faster? And I just — I'm not sure that's exactly the right instinct. I would be thinking about how does AI let me do it better rather than faster. And I think when trying to talk to users, I don't know exactly how it would make it do better versus sitting next to them.

Okay, so we talked a bit about like early building. Let's say now you have something that works and you're looking to scale up and you're coming to Dalton and asking for a Series A. Like the companies that are reaching this stage in 2026, like are they different to the companies that were coming in 2020?

I think it's similar to what I was talking about a moment ago where the bar changes because of what's happening in the rest of the market. And so it is true that there's companies growing incredibly fast like yours, and that if you turned in these growth numbers 10 years ago, again, you're already one of the fastest-growing companies in the world. But imagine if you turned in these numbers 10 years ago or 20 years ago — it's mind-boggling, right? And the growth of

What about team size? Is that different?

Yeah.

Yeah. Actually, there's obviously a lot of overlap of how we run it because we both take bits from the GitLab playbook for sure. And I think like one thing we do which has always been a bit weird because we sort of started out as a multi-product company, we have the database, we have auth, we have edge functions. We always basically hired the most senior person we could find to run that small team and then let it operate like its own startup. And even now, people ask internally, oh, what's our internal AI policy? Like, are we going to be like rolling out Claude Code to everyone? Are we going to do it this way? And the answer is still like, well, let the teams decide for themselves like how they want to run it. So that's one thing that's probably different for us than most. And honestly, like it would be very hard to do it the other way in a fully remote environment. You know, we're 450 people. We're in 75 countries. If me and Paul felt like we needed to like make every decision, that would just be a nightmare. Honestly,

Honestly. And the interesting thing about Supabase is very early on, and it was difficult in the pandemic because everyone was remote all of a sudden and everyone was like, yeah, I love working remote. We quickly started to hire people who actually that wasn't their preference and they had a really bad time and they're like, can we jump on a quick call? And me and Paul are like, absolutely not. So, and not even I was going to say send me a DM, is we push everything into public channels because if me or Paul are asleep then someone else can answer in a different time zone. So I think it's definitely different but I've also observed over probably the last 12 months is a lot of YC startups now are going back to being in office. They were doing like the 996 thing like...

997.

Yeah. Yeah. Yeah. No, great. I just wanted to talk about quickly like the things you use AI for. And Michael, you said like it sounds like you are a non-technical founder getting the bots to do a lot of the technical work. Yeah. In your like day-to-day lives, what are the things that you're not willing to hand over to agents?

What do you not use it for? Because you want it to go through your brain still.

There's no script.

Yeah. And just a quick anecdote to end on. So we did YC fully remote and we would have calls with Michael every two weeks in the batch and he would always ask, you know, what did you do over the last two weeks? And we said, oh, we're building our auth service. We didn't have auth at the time. And what are you going to be doing for the next two weeks? Oh, we're building our service. After about six weeks, he was like, 'Guys, like, you've been telling me that you've been going to ship your auth service for like the last six weeks. Like, what the are you doing?' Basically,

No. Actually, and the thing about Michael is I've never ever met anyone who can give you like such direct advice, but you still come away like feeling great. It's like a very special skill that I think you've got. So we came away feeling great, but we're like, we better ship auth this week. So yeah, very, the office hours was extremely useful for the Supabase story. And now we're out of time, but thank you so much guys for joining us and round of applause for the guys.

All right. Amazing. All right. Thanks, guys. Great job. Okay, everybody, hold your seats right there because at 2:05 in a few minutes we are going to start again with Thomas Dohmke who is the co-founder and CEO of Entropy, the former CEO of GitHub, and Alana Goyal the founder and managing partner of Basecase. So we'll be right back.

Hello. Hey, welcome back. Okay. Thanks for hanging out. If we could, quiet down for a moment. Now joining us on stage are Elena and Thomas.

Thomas, thanks so much for being here.

Thank you so much for having me.

So the title of the discussion for the next 25 minutes is what happens to the software development process when agents are writing most of the code.

Yes.

So I thought before we began we can ask the audience. Let's get a quick show of hands. Who here is having agents write the majority of their code?

Now keep your hand up if agents are submitting most of your pull requests without you involved. And keep your hands up if agents are reviewing and merging those pull requests without you involved.

Okay, let me add one more. Keep your hand up if you told your agent what the... Yes, the largest show of hands. Yes. So, Thomas, you've had a really awesome career. Like, you ran GitHub through the Copilot era and then you decided to start over as a founder. So my question for you is what did you see that gave you the conviction to start Entropy and maybe give us some context on what you're building now?

Everything that you already asked in your questions I saw happening live, you know, at GitHub. And a year ago or so, I started to really be convicted that agents will write most of the code and review most of the code because we're all doing it ourselves. And while there are still moments where you have this WTF that you put in the prompt because AGI isn't actually here and we still have to have engineers to tell the agent what to build, I was convinced that it's now time to build a new developer platform and build a startup from scratch, AI-native, quote-unquote, because it's so much fun to do that.

Yeah. And my next question for you is I think right now starting a company is pretty awesome because you can start from scratch. You can be fully AI-native from the start. What does the process for agentic software development look like for you guys at Entropy? Can you describe that end to end?

I think the first one is that you can be the CEO founder of a company on stage at Supabase Select and have the agents running writing code. They're always going.

And they're always going.

And I think, you know, some of the anxieties that we have as founders and as developers now, I'm sure some of you have that as well, is like how do I keep them going and how do I make sure that I'm not going to sleep or board a plane or, you know, go to a meeting or a fireside chat and the agent stops with a dumb question and where I'm like, I told you all of this, there's the plan, you have your goal, go and keep running. So number one is you have to figure out as startup, as engineer, how can I keep my agents running, how can I have them build what I want them to build while not burning tokens needlessly. I was at a hackathon last weekend and I was discussing with some of the students at Georgia Tech and the point was, you know, it's no challenge to win a hackathon where you get prizes in the size of thousands of dollars if you spend tens of thousands of dollars in tokens, right? That's just economically stupid, if I may say so. I think so that's number two. It's you have to actually make that sense for your company from an economic perspective or for the project that what you're building with agents is faster and cheaper than engineers doing it because otherwise you can just hire more engineers. Like the more, you know, real-life example is that it's still cheaper to hire a human housekeeper that manages your kitchen and your dishes or your bathrooms and whatnot than buying a robot doing that, you know, half-ass, if you will. Yeah.

And then I think number three is similar to Supabase. We are a fully remote company. We have folks in New Zealand, Australia, India, Europe and here in the United States. And in the world of agents that's really cool because by culture everything is written down, right? We have everything in GitHub, everything in Slack. Obviously we have now more and more stuff on our own platform. You know, we AI transcribe every Zoom call and so as a company now our agent in Slack can be asked about anything, what was happening in the meeting, what was happening in our codebase. And I think that's super, super powerful.

Yeah, exactly. Before I get into the next question, can you ground us a little bit in what you're building at Entropy, sort of the premise of the company?

Yeah, the premise is three-fold and I try to keep it short because I love talking about this for hours on end. We're building three new layers. We're building a new code infrastructure to store your Git repositories in any region around the world. So think about it like GitHub but you can have your repo in Europe, in India or in Australia, in any AWS region in the future. Number two is we're building a context layer. So we're capturing all the agent session logs, whether it's from Codex, from Claude Code, from Pi, and it's open source. You can extend it for any other agent and we're putting them in Git next to the code. But it's not a file in your repository, it's an object in Git. Think about it like Git as a database. And that means for every line of code we know what session log created that line of code. And you can basically not only get blame but you can get why or get how to figure out, you know, what prompt created that session log but tool calls and so on. And then on top of that we are trying to reinvent the software development life cycle saying not only is code all generated by agents, code also should be all reviewed by agents and you should have a user interface or user experience really where your agent can decide whether all the evals are green enough to automerge.

So I mean everyone here is used to committing code on GitHub but I think committing agent traces is like a very new paradigm. Yeah. Do you guys do that today? Like what does that actually look like? And maybe like share some fun examples of like things that you found that have been in the logs.

Yeah, I mean the fun example, we have a Slack channel, my agent says, where our folks are posting all the dumb responses that we're seeing from agents and you can actually extract them from the agent logs. Everybody at Entropy is automatically capturing all their agent sessions, all the agent coding sessions I must say, and storing them in all repositories. And so we have thousands of these sessions across multiple repositories. And that means not only can you, you know, digest them to see what prompts did the developers write or what did the agent respond and was it funny or not, you can also summarize the daily or weekly work. And so instead of, you know, coming up at the end of the week with your progress update in Slack, you can have the agent write that for you and then you become the copy editor for those logs. You can identify that, you know, the same agent every time tries to install, you know, the right version of Python because it's missing on a cloud sandbox and then you can fix that and so you reduce token waste if you will. You can see things like in the code review process yesterday we saw that the agent identified security issues but then also found the architecture decision records, the ADRs in the repo and assumed that those were correct and then discarded its own security finding. And you can figure that out if you store all the session logs because then you can review those, you know, after the fact a day later or a week later. You can always obviously also see in those session logs if you think about like multiplayer what other people are working on and so you can find out that three people in the company are building the same component in design system or the same payment integration or the same, you know, Supabase optimization and so we think that's super powerful. There's some, you know, I think discomfort with some of our design partners saying not all our engineers really want to have all their sessions stored in Git or they worried about, you know, an MCP call address accessing a customer database and pulling, you know, customer context into the agent and then storing that forever and for perpetuity in the repo. But given our CLI is completely open source, you can actually just build your own filter engine or you can just say I don't want to attach that log to the commit and as that, you know, the developer stays in control which is what I always believed in.

And I imagine like, you know, dogfooding this yourself you get to see lots of different things across all the different coding tools. Personal favorite coding agent right now?

Codex. And my favorite is Codex because I think the remote control system works really well in Codex. So I have, you know, three Macs, one in Germany, one in Seattle, and one with me. And the one with me I obviously have to close when the plane is taking off and landing. The other ones are... And then you pick up your phone. And so I have my phone and a remote control into the Mac up in Seattle. And that's actually an old 2019 Mac Pro. So it runs an Intel processor and has like a, you know, standard graphic card. And so I use that for more like backend stuff. And then my MacBook in Germany it does more frontend and building 3D Star Wars games and whatever have you. But it's really this, I think the superpower now is that you can just speak into your phone. I was, you know, coming here from the airport with bot and I was literally just dictating into my phone the next prompts. And that works super well for me in Codex but we give everybody in the company the choice and so we have people on Codex, on Claude Code, on OpenCode and on Pi and on open models and so...

Okay. Interesting. So, you don't have like a company-wide mandate?

No, we're a startup. We want to move fast. I think that's the superpower for most startups. Fast decisions, fast turnaround times, fast iteration with customers. And so we don't want to tell our developers which agent is the best. Right now, it's a different one every...

Well, okay. As a nerd and I'm sure there's lots of fellow nerds in the audience that want to know, is Git going to stick around? You know, with the volume of agent traces and of code going up so much, do you think Git is the primitive?

I think Git as a version control system will be around for as long as you and I are on this planet. The ecosystem is just so massive. You're not going to, in today's world, you're not going to go to the big enterprise and convince them to move from Git to something else. It's just too painful. There's too many tools written around Git. There's too many integrations. Obviously, Supabase integrates with Git, Vercel integrates with Git. You know, all probably all the sponsors of this conference all integrate with Git. And so introducing a new version control system in a world where most of the Git commands are all written by agents is not going to be a successful vector. What we believe, that's why we're rebuilding the backend, is that you can make it much faster by... we rebuilt the Git stack on the backend side and others are doing that too. Cursor had a great article on their blog of how they rebuilt the Git backend. I think there's multiple approaches to do that. We believe in a distributed approach. We have cells around the world because our agents and our GPUs are also going to be around the world. That brings down latency, that allows you to hammer those cells with much higher rate limits because they're not having noisy neighbor problems. So not sitting in a single region. I mean, I'm preaching to a choir at a database conference that is distributed. And then you have all the data residency questions, GDPR, geopolitical questions as well. And so we believe the future is actually quite similar to what Linus Torvalds thought about Git in 2005. It's distributed.

Putting aside the practicality of Git, if you just could do whatever you wanted and like design your own system, what would that look like?

You mean like my own version control?

Yeah. Like is there anything you would do differently or you actually think it is the perfect system and it's not just like for sort of...

I mean nothing in technology is really perfect. I think, you know, the biggest issue that you'd always had is that the how to use it is too complex. Like the command line was complex to learn. Then you have two branches and do a merge or do rebase and that doesn't matter anymore. If you try to teach that to, you know, a sixth grader that only really wants to build their own Minecraft, and that doesn't really care about version control anyway because they haven't gone through the pain of, you know, a V1 and a V2 folder and a V3 folder and I realized in between you lost something really cool that you built at night. That's how we all grew up before version control, before we used CVS, is like we had version folders and at some point, you know, you messed it all up and half your work was gone and then you went frustrated to bed. But I think the user interface of Git and some of the intricacies of Git, they're not perfect. But rebuilding that instead of just telling your agent to do it and the agent today can cherry-pick commits, you know, out of a branch, it can rebase the whole thing. It can rewrite the whole history. In fact, you can, you know, create demo repos with thousands of commits in no time with an agent and you don't have to worry about how to do that in the Git database. I don't think there's any... it's not exciting I'd say to build a new version control system. I think it's much more exciting to bring version control and databases to young people and explain to them that, you know, vibe coding a game is super easy but then learning about Git and learning about databases, Postgres and Supabase, that I think is much more of a challenge and one that is really exciting because it expands the market of our companies.

Do you think kids will still memorize Git commands?

Or they should probably not. I think they should learn about it like in the same way that, you know, who still knows, you know, all the parameters behind sed or grep? Who even knows how to open a man page anymore in, you know, the generation that's growing up right now. But I do think that kids have to learn coding from an early age in the same way they learn physics and biology and all that because that's such a foundational technology on this planet and I hope many of them will get into coding because it's so easily approachable now through these super apps like GPT and Claude.

Yeah, one of my favorite assignments was rebuilding Git from scratch and obviously like...

You're not building Git because you need to build Git, it like exists already, but it's to teach you how it's done and I think that although you don't need to like build things from scratch these days it's still important to learn how to do it and...

I think that's what universities will do. They will give students assignments where they use an agent to rebuild Git or rebuild the Linux kernel or rebuild Postgres and then explain, you know, how it works and find optimizations in those rebuilds while keeping the interface stable.

Without agents doing it for you, I guess? Or at least if agents do it for you...

I think the agents should do it for you, but you as a student or as a developer need to be able to control it and need to be able to understand it and need to be able to look at the output, you know, after 12 or 24 or 48 hours and say, okay, what you actually did is what I wanted. And we can use agents to verify this, but I think we all have been in a situation where you had one agent build something and the other agent confirm the thing and then you look at this and you're like, what is this? And yeah, there was a judge but the judge only got the wrong instructions from the coding agent to review its own work. So you have that confirmation bias between agents.

Yeah, I think you probably see this because you have like, you know, you log agent traces and you have people in your company using a bunch of different things, but how do you actually measure productivity? Like, you know, years ago the 10x engineers, like, you know, you submitted a lot of PRs. Now you can submit a ton of PRs and they can all be slop. Like how do you think about that?

I mean the simple answer as a CEO founder or even as the CEO of GitHub or before that as, you know, product manager within the larger Microsoft family is like productivity is when all the features that I want to ship by the conference, so the CEO or the spokesperson can announce it, are actually shipping. And conference-driven development I think is, I mean we're at a conference here. I'm sure there were super exciting announcements this morning and the team...

They were working this morning.

The team was working to make that happen and so Paul is happy if they're shipping and he's not happy if they're not shipping. Other than that, I'm not a big believer in engineering productivity as a metric because engineering is not a factory. A factory is you have inputs, you know, you have materials that get into the factory. You have a pipeline like a moving assembly line, whatever, and then you know exactly how long it takes to make one part and it comes out on the other side and the only really unknown is the quality control and how long that takes and they have processes for that. Software engineering has never been that way. You have somewhat known inputs but they're constantly changing. That's why we believe the session log is much more interesting than the spec because a spec is never stable. That's just a pipe dream of people that want to sell spec-driven development. In real life, you're prompting, you see the output and especially if you build something visual and then what you thought when you initially prompted it wasn't actually true and you are like, oh, I thought that was what I wanted but I actually want a different thing and you keep iterating on this and at the end of your, you know, three-day session with Codex you got to a totally different result than at the beginning of this. I'm working as a side quest on a little game and, you know, I started the session to make the graphics better and in between I like, I wanted sound and so I started working on sound. And then I didn't like the sound that the robot made. So I kept iterating on that. And so by the end of that session, the session was about something, half of the session was about something completely different than quote-unquote the spec was in the beginning. And so engineering is a process that is much more like art and creative art than it is producing parts. And as such measuring productivity is something that you don't know what's below the denominator in the first place. And I think from that perspective it comes back to if I said it in the beginning is you're investing tokens or energy or whatever, you know, your metric is and you're getting an outcome that is a feature or bug fix that you're shipping to your customers. And at the end of the day what we're trying to achieve as companies is to raise revenue at positive profit margins, right? That is your productivity metric and I don't think anyone in the industry today can draw like a clear line from the idea that you're having, the feature you're building, the code that it's shipping all the way to the revenue increase. And so that is the challenge, but that's also why I think our industry is so much fun.

Yeah. Well, you obviously write a lot of code yourself. You were telling me about the side project. I'm curious like if you sort of rewind like a year ago today, how was your process different? Like were you still running Codex on Mac minis? Were you doing like long-running agents? You said, you know, might take three days to go on an agent trace.

A year ago was, well, October 2025. Everywhere like right before that explosion where, what was it back then, the Opus model and I think the Codex model was probably Opus something, maybe 4.5 or 5, something like that. And then OpenAI came out with a Codex model that in November timeframe were so good that you could actually move to, I'm prompting it, having it write code, I look at the code, I realize it's so good that I don't want to look at the code anymore. And so a year ago before that I think we were still in this assisted development stage where you were using, we were using Claude Code and Codex and obviously Copilot and Cursor, but a lot of that was still like the level of trust was not high enough. It's kind of like, you know, now the agents are like Waymo, you get into one, it gets you somewhere and you don't look what it's doing. You're just texting your phone. You're listening to Bon Jovi because it syncs to your Spotify playlist and whatnot. But if you have a car with self-driving you still have to have your hands on the steering wheel. And depending on what manufacturer you're having, you have to pay more attention or less. But as soon as you take the hands off the steering wheel, all the cars out there right now start nagging you and then eventually it starts slowing down and the car goes into alarm mode that you're not paying attention. That was what coding was a year ago. A year ago you could build with agents and it was more productive than building without agents, but you couldn't take your hands off the steering wheel. Now you can take your hands off the steering wheel, but only until you get out of the coverage area, you know, until you get to Oakland and then you have to pay attention,

Look around, make sure you're in the right spot.

Yeah.

And maybe if you think like a year from now, you know, when we're back at Supabase Select for the third annual conference, do you have any predictions for what's going to be different in your workflow or just the agentic development process in general?

We're moving to more factories. And with all the caveats that I made earlier, which is I think we're going to give bigger tasks to agents. We have those agents running for hours on end or for maybe all night long or it's Friday afternoon now so hopefully for all the weekend and we don't have to check in with the agent on Saturday. And we're going to have a code review process that is also driven by agents but different agents than the ones that are coding that evaluate the work of the first agent. And it's not a once-and-done loop. It's a continuous loop until the coding side and the code review side have kind of created like a stable state. And then I think we will have a signal whether a human review is required or not and we will define what that means for our company. And by the way, all of you that sell software to enterprises, you all know, so what SOC 2 is, SOC 2 actually requires human approval. So if you want to stay compliant with your compliance process and what you're promising to enterprise customers, you can't literally auto-approve work by an agent. And in fact, if the code is all written by an agent without human involvement, you need two humans that approve. But leaving all that aside, I think we're moving to much more of that kind of like loop where agents working with each other until they reach stable state and then a developer or a builder like we like to call them will look at a dashboard and see metrics, a confidence, you know, security, drift, slop. We have a slop meter in our company to see, you know, what the agent produces matches our standards. It's not about, you know, AI generating slop, it's about how to prompt AI to not generate slop or to remove slop. And then we will just, you know, thumbs up as we have always done, especially on Friday afternoons, right? Because many get a pull request, got no code review at all. All they got was a LGTM thumbs up.

Yeah. Does having the agent traces actually make the review better in your experience?

Because the agent trace is exactly reflecting my intent, right? And you cannot argue after the fact that's not what you wanted because at the end of your session with your agent, you do make a decision to commit and push and open a pull request or how we call it a trail. And so the agent trace is the best way of reflecting what did the developer actually want. Right, all my prompts that I gave it or the reference to my skills files, my agent MD, you know, the corrections that I gave it, the steering, whatever it is, it reflects all my tool calls. Right, the agent is logging all its tool calls and the agent trace often has also the response to that call involved. So if you're pulling some data from a Supabase database and you get that data back and the agent uses it as context, having that actually available in the code review is incredibly valuable because the reviewing agent can then look at that data and say, well, that was actually an edge case and the agent hasn't really proven that the algorithm that you're building, you know, in your change works for all the scenarios. You know, the agent reflects all the test cases it wrote in the agent trace and it also shows whether that actually executed those tests. And let's face it, you know, when my agent tells me that it has ran all the tests and 58 out of 58 passed, I'm not looking through the trace and actually validate that. I just trust the agent. So having the code review agent, having the code trace, the agent trace available and pass that and actually use that as provenance to say what the agent claimed it did did actually happen is incredibly valuable. And that's why we believe having, you know, the code, all the traces and then a loop between the coding agent and the code review agent. And we will always give, you know, our customers the choice of what coding agent and what code review agent they want to use. That is going to create a process, a software life cycle that lets us run this much more automated and not look through every single line of code.

I'm curious, has this made you a better prompter? Like knowing that your agent traces are being logged, that it's like, you know, literally taking what you said to what is actually happening. Does it make you more thoughtful about things? I mean, at the beginning, I guess you said you still say WTF to your agent. Sometimes.

It makes me feel that I'm a better prompter, but I'm not sure that's actually true. And I think that those doubts always come at the moment where the agent didn't do what I thought I had clearly specified. And so I think we're all still in a loop ourselves of learning how to work with the agents, with a harness and with the latest model or even, you know, working with a super powerful model like Astra Ultra and then telling Astra Ultra to spin up sub-agents on cheaper models and offloading the work there. Even that I sometimes have the feeling I tell that the agent but it doesn't actually do it when I look at the pricing sheet or the token consumption afterwards. But you can at the end of every agent session ask your agent how many tokens it spent in the main session in the main agent on the expensive model versus all the sub-agents on the cheap models. And oftentimes I come out and saying do all the work in the sub-agent but in reality I spent 90% of the tokens in the main agent and very little in the sub-agents. So I think, you know, that is going to define a good engineer is the one that will learn and create best practices around how to be most efficient with these powerful agents. And I would say I'm maybe myself at the 60th percentile or so of how to do that. And some days I feel like I'm at the 10th percentile and other days I feel like at the 90th percentile until I'm being back on the ground and realize, okay, I still don't understand how that actually works. And I think the challenge that most of us here in the room have is that I don't have unlimited token budget. I can't, you know, spend all my seed round investment into tokens because then at the end of the day I'm not having a business, all the frontier labs have a business.

Yeah. Well, super quickly, Thomas, what's one piece of advice you have to everyone in the audience who's going to go back to their agents after this?

For me, I think the biggest thing right now is how much fun it is. And so the advice I would give everybody is enjoy it. And find the moments where you use your agent to build, you know, the side quest, the hobby project that you always wanted to work on. It used to be that on Saturday you would wake up and you have an idea for the weekend, something you want to build on, and then you spend a little bit of time on Saturday, on Sunday on it, and you spend more time on Stack Overflow or on npm installs or figuring out how to force it into Python 3 instead of Python 2.7. And by Sunday night, all you actually got to is setting up your environment and running your to-do list and you got nothing done. That's no longer the case. Now you can on Saturday spin up three agents, give them all three ideas and at minimum on Sunday night you have a prototype of that idea. And I think then it's totally fine to throw away those prototypes in the same way that you're throwing away your notebooks or maybe archiving them. But a lot of the thoughts, a lot of the self-reflection that we do in our careers is only for ourselves. And I think working with these agents only for ourselves to improve our craft and enjoy it. That's my best advice I can give because I enjoy that so much myself.

Yeah. Well, thank you. This is so much fun.

Thank you so much.

All right.

All right. Thanks, Elena and Thomas. Okay. So we will be back at 2:40 with Parag Agrawal the founder and CEO of Parallel Web Systems. He also was the CEO of Twitter and Karen Maroon who is a GP at Co. All right. So 10 minutes. Thanks.

Go.

Heat. Heat.

I feel it coming. I see it going. Take me higher. Take me higher. I feel it coming. Come on and show it. Take me higher. Take me higher.

Okay. Hey everybody. Uh, welcome back. Uh, okay. So coming up now is Parog Agarwal, the founder and CEO of Parallel Web Systems, and Karen Maroon, a GP at CO2. Uh, round of applause, please. Thank you.

Hey everybody, thank you for staying with us. We're thrilled to be here. I'm thrilled to have this conversation with Prague. So for those of you that don't know what Parallel does, can you start with what it does and why you started saying AI agents need an entirely new web infrastructure before AI agents were the thing that I think everybody's caught on to? What do you do and how did you see this so early? Because this was 3 years ago.

Yeah, 3 years feels like a long time ago. Well, hello everyone. So nice to meet you all. I run this company called Parallel. We're 3 years old. I got obsessed with this notion 3 years ago that agents will become the primary customers of the web and they'll use the web a thousand times more.

Which at the time a thousand times more sounded nuts.

Oh yeah, I think I got those reactions when I went around raising capital from some people. Luckily there were some other people who took the leap of faith. And yeah, it was like a made-up number, right? Like today I think I undershot on that number. It's going to be more than a thousand. And at the time I did not think it would progress this fast in terms of how agents come online. And I think today if you have to sit here and say things like I think there are so many things where that's going to happen, like agents will use databases a thousand times more, they'll use computers a thousand times more, like you can apply that to a lot of key ingredients that go into consuming things at least at the infrastructure layer in order to get stuff done.

So to take us back three years ago, many of us know you were the CEO of Twitter and you said, 'I'm going to do something new.' I mean, some of us would have taken a break, maybe a little vacation. You are incredibly driven and you were like, 'No, I'm going to solve a problem.' How did you see this problem early on when, I mean, being on the other side of the table doing investments, none of us were seeing this problem then?

So yeah, I think I got fired from Twitter at a very good time.

We're having a minute. We love you.

And so, no, I thought like it was clear in that moment like I had been pretty close to AI and was like deep in using these models at Twitter and outside. I wanted to do something new. I was on the hunt for where you could make a big dent in the world. But this problem, this obsession, it actually found me instead of me going and finding it, like I was looking for other areas and other things. But I don't know, I think a lot of people here, at least in this crowd, will relate to this. I'm the kind of person that was like goal-oriented in trying to do something, but I was spending time setting up my IDE, which effectively in that moment was I was trying to build agents to do work towards understanding the world that I wanted to understand to start a company. And at the time the models weren't good enough. I had access to very little. I was unemployed and sitting in a coffee shop, and I had access to models, APIs, I had access to the web, and my email just isn't interesting enough for agents to use. And so I was trying to do stuff with agents in the web. And I saw that the web was a very hostile place for agents.

Hostile.

Yeah. I think you'd get blocked all the time, even then, because you would be like a bot. You would run into walls. You would get a lot of junk back, and the models then were not good enough to deal with the junk and the noise that you get back from the web. And so yeah, you could see all of those, and you could see how if you built something to make life of the model or the agent better, it would look very different. And through that sort of lived experience hacking, it became very clear to me that if you believe that models will keep getting better, that we would have to invent an entirely new set of technology to power the web for agents.

Yeah, and business models alongside that technology to align the interests of people creating content producing on the web. It's very clear advertising is not going to cut it. So the combination of a technology problem at a thousand times Google scale plus new business models that need to get invented is enough to make it like a real obsession for a decade or two.

So I think I'm trying to picture you in the coffee shop with this idea. So you think you're going for some holy grail of something else. And in order to do that, you realize that you hit all these barriers when you're trying to work with agents. At that time, you weren't building for a specific customer. It's not like there was a customer saying, you know, get me this now. You know, there was none of that. So you had to think, I'm going to build this in isolation almost, assuming it's going to come or believing it's going to come, seeing that agents are going to become the way that people are researching and carrying out tasks, and then you have to think, and the business model itself has to change. So here's a bit of a, what do I call it? I also worked at Meta for about 10 years. So I have a moment of like we have that in common where we were at those kind of businesses with the whole, and the business model is a really important characteristic to take into consideration when you want to build an important new infrastructure company. So how did you have the strength to build for no particular customer early on, and then how did you move that forward knowing you were going to need a new business model attached to a new technology?

Yeah. So,

And maybe explain how the business model works now, because people might not know that.

So, I don't know, like I think starting companies or even working at early stage companies when this zero to one phase are acts of irrationality which are kind of hard to justify. But I think for me it was really this sort of at the time ChatGPT did not do web search as the product, and so it was just you talking to a model. But then as I was going through this obsession, there were a bunch of, I don't know, people here probably played with like BabyAGI and AutoGPT, open-source agent hackery that was happening in the open source world, and I was doing a lot of that. And you could like, I think if you do these things, you can sometimes feel them to build that irrational conviction if you may. And then you find points of validation, right? Like as you build, a new model comes out and it's like it's trending in the direction you thought. At some point ChatGPT ships web search and your lived experience with it evolves. Before starting the company, I went through a five, six month journey to go talk to a lot of researchers at the labs to talk about like how will the models progress, will the models subsume the web, will they not, how will the various people building at the time, you'd call them like chat applications but not agents, how were they thinking about the web. You could put a lot of these sort of, so it was not like me YOLOing a company. I spent, I want to say, four, five months of intense effort trying to understand how will hyperscalers respond, how will incumbents respond, what they can and cannot do. Went and understood, spoke to publishers and content owners about, which was like a weird set of conversations because they're like, what are you talking about? But I did a lot of work to take this sort of science fiction obsession and paint a very detailed image of the future. And I don't think I was right on the details, but I think on the macro we mostly got it right.

So you have said, I'm going to get this wrong, but human clicks are a bug. So when you're looking at search and you're trying to understand that is absolutely now sending us down the wrong path. Can you explain that?

Yeah. So there are two things. One, people have been long primed to think that if you experience and see human clicks, you have this sort of amazing training data from which you can learn a bunch of things. And yes, there is value in human generated data at scale. The reality is human clicks are very, very noisy. It takes a lot of work to remove all of the noise to pull out the signal in a human clicking through a product like a Google search. Turns out that you can train agents to provide better signal. Also, the things agents want are different from what humans want. So if you go take all of this sort of human click data and you train the best models using that or the best rankers using those, turns out those are not great models for figuring out what to show agents. I can talk through a bunch of examples about like what we've seen along this journey, but I can ask first principles, okay, what is the best way for an agent to be successful at what it's doing, and designing our products with that singular focus. Turns out like if you use our product, which is a search API that agents use as a human,

Wait, and did

You would hate it.

You hate it.

Yeah, it's just not good. It's like it's great for agents, it sucks for humans.

That's really... So, and didn't Google just... Aren't they using you now for their enterprise APIs?

We have a partnership with Google Cloud, where we provide search to ground Gemini models. It's baked into the product. It's baked into, we do a bunch of GTM with them. Yeah, it's pretty fun to sort of be search for GCP.

That's kind of its own. So when you think about with agents doing so much of this work now, what are people still getting wrong in research when they set out and they think this is going to be a great task, that this is going to work for agents to go out and do this research, but they're foundationally getting it wrong and why?

I think to me it's, I think actually the biggest problem is the interface problem right now that you see. So for a sufficiently well-specified task with a sufficiently smart model, of which there are plenty, even if they're somewhat expensive at times, they can do a fairly good job. The problem is we struggle to specify tasks well enough or provide them all of the context that's sitting in the back of our head as hidden criteria. So if you took a particularly well-specified task for an agent and gave it all of the access and the tools needed to do so, they're shockingly good. And so the one area at least on the web where they struggle is sometimes because they can't access content that you can, or they can't take an action because they don't have the privileges that you do. But I think if we clear those hurdles, agents can actually do more than most of us are getting out of them.

Okay, we have a rise of consumer personal AI agents. Like just this week, another one was announced. And I'm curious in this audience, how many of you use Muse? Raise of hands. And how many of you use Instinct? You and I both use, I use both. And dots. I don't even know if we can. Okay. So do you think that people will use just one ultimately? Do you think that, and I'm curious when things go to a consumer side? We've been talking about agents on the developer side. How does this change the way the ecosystem will respond now that there's a consumer use case for the world to access?

Yeah, I think and

By the way, did you see this three years ago? Could you imagine that we'd be talking about agents as if it was, you know, it came up in my, I ordered a car this morning on Uber and I got ads for personal agents and I was like, how did this happen so fast?

Uh, yes. I think 3 years ago, we were totally visualizing enterprise and consumer agents. At the time, my intuition was that the world of enterprise agents will be highly fragmented. Each enterprise is like a weird bespoke beast, and so it's just very hard to build a singular product that solves it all. It can break down by the history of the toolkit of the enterprise, by the industry of the enterprise, by the function. There are like many dimensions of complexity across enterprises of various scales that I had pretty strong intuition that the agents in the enterprise world would be fragmented. Consumer, I continue to believe, will be far less fragmented than enterprise. We aren't really placing any bets, like none of these things, points of views of mine are strong enough. Generally my market is super fragmented,

Which is what I want.

And it appears to be shaking out that way, but I'm not placing real bets around how the consumer market shakes out. Generally as a startup founder, I'm on the startup rebel alliance. Like I want the best products to be built by startups. I don't want large big monopolies. I want the best product to win on merit because people obsess about building with deep intensity really amazing products for the customer versus exploit market power.

Yay. I think we agree and it's really exciting to see this. It feels like a burst of energy and creativity that's going on. And when you have these consumer products that are mirroring enterprise products, I think it opens up people's eyes to understanding what to do in both sides. So I'm curious when you think about, let's fast forward a couple years. What you want to pick? One, two, three, five, a period of time, three, three years. What are you so convinced of that is so obvious that this is the way it's going to work that wouldn't be obvious to most of us here that you can see as clearly as you saw the thousand time usage of agents three years ago.

Yeah, let's pick three years because I still can't believe you can see that three years ago and now it seems pretty obvious. I think most of the usage of the web 3 years from today will be push rather than pull. So today your agent goes and searches the web. Sometimes when you ask it to do things, sometimes when it's running on a cron in the background with the heartbeat or whatever. But mostly its interactions with the web is it will go to the web through a search engine. It'll fetch some pages. It'll process them and it's pulling content from the web. That's sort of how the web is used today. My prediction, which I'm betting will come true, through, assume today is, most of this usage has shifted to your agent consuming a feed coming out of the web, like perhaps your social media feed as a human or the union of all of them, where what should it know from everything that changes on the web as the things that it must either know or act upon or respond to or make its master agent or master human aware of. So the web will feel like a subscription that an agent personalizes about like, oh, send me things relevant to me, and the web system will have, will be provided by this agent enough context for the web system like Parallel to be able to funnel to each of your agents the relevant data stream.

So we're talking a web that is push, not so I don't ask, it tells and completely personalized and proactive.

Yes, personalized, proactive. So things that like

So how's it going to know before I even know to ask?

And am I going to like it or feel like it's creepy?

Or both?

I think there might be moments when things feel creepy when we don't productize it, right? But then it'll be just the way

The way

It changes.

Um, no, I think we've listen like

People have tried to move things to highly relevant notifications forever, right? Like this is not some new idea. Like I think what Google Now was supposed to give you notifications, there have been many, many efforts around this. Google Alerts has existed, right? We've just never had the ability to have sufficient intelligence that is cheap enough and good enough to have simultaneously high recall on this feed about like it'll tell you almost everything you need to know and high precision that it's not going to waste your time. Right? To achieve that requires extreme amounts of context but extreme amount of intelligence boiled down into tiny, tiny cheap models and levels of compute which is the direction of travel which is what we're betting on.

Okay. So I see this future in 3 years and I now see the thousands of agents. I want to have a moment because so many people here are founders and you've run Twitter. You could have stayed in a not even a coffee. You could have taken a break, done a vacation. You could have, but for those of us that know you, you are so hungry and so driven and so I don't even know if there is an off switch. Like two things here for founders. One is how do you know when it's worth it? Because so many of us work on things and then at some point we go like, was it worth it? It's so hard and there's all different ways of trying to understand if something is worth it. How do you figure out if it's, and I use this like worth it because we're spending our life's time on this and you have to take a moment and reflect like you could do anything. How did you say like this is worth it and this is what I'm spending my life's energy on and you for again energize the out of it like you are so on and so in it more than ever.

So a couple things here. One, when I was going through the journey of figuring out what's next, I think I was working as hard as I work right now because I was sort of consumed and obsessed without a goal. Two, I got a really good piece of advice by Josh Kopelman who happened to also invest in the company. Like

I love Josh.

6 months before I started the company,

And he said listen you're about to found something,

Don't rush it because no matter what happens you have to believe that you're stuck doing it for 10 years. People can, if you join a startup you can quit in a year when you regret it. If you found a company especially as you with your background around people are going to fund you, people are going to join you, and then you cannot quit. And you know if the company dies in a year that's not bad. The worst thing is sort of some form of mediocre success that is on the margin of it being worth it and I think that sticks with me. And so my job is to be super risk on. I only do things that I really deeply enjoy. So if I'm like not energetic, this thing is not going to work out. So I like to work on things that like just drive me. I gut check myself. Like I live in this state of simultaneous extreme paranoia as a founder must and go through like an emotional cycle every weekend where I think like the world will come destroy me and extreme optimism about what we are going to accomplish. I think literally if we do our jobs as a company and we've really talented people some of whom are here, if the world spends a bunch of GPUs on models it should spend 10, 20% of them doing web search in the push model I suggested and I've done a lot of analysis, a lot of experimentation to have conviction in what that will look like and we should be the absolute best at that and we should create incentives for anyone putting content out on the web which by the way is going to blow up because we're all going to use agents to publish. So the rate of change of content on the web is going to be extraordinary. And then you have to pull out the signal from all of that noise to give to somebody else's agent. And so you're stacking somebody's compute, producing, pulling the signal out of that compute and give it to somebody else's agent, somebody else's compute. And so we want to be this core part of this feedback loop and it could have such a material impact to the world that like how do you not show up with all this energy?

I love it. Thank you. Thank you, Prague. Thank you everybody.

Okay. All right. Thanks, Karen and Prague. Okay. So, we have another 10-minute transition and then we will have a session with OpenAI. So Paul the CEO of Supabase is going to be joined by Jeff Chan the engineering lead for OpenAI's API and Nikun Honda who is the head of product for the OpenAI API. So I will see you here at 3:15. Thanks.

Hey everyone. All right, welcome back. Okay. So, now we have an OpenAI session. So it's going to be hosted by Paul Copstone, CEO of Supabase coming on stage and he'll be joined by Jeff Chan, the engineering lead for the OpenAI API and Nikun Honda, the head of product OpenAI API. All right, round of applause please.

Okay, so I got to start off by saying that OpenAI has been an amazing partner and we launched I think sign in with ChatGPT, I don't like it's hard startup time is a little bit dilated so I don't know how long ago it was but now it drives 20,000 signups per day to the Supabase platform which is pretty cool. So maybe we talk a little bit about how you think about ecosystem. How do you think about partnerships? What's the strategy for OpenAI and especially around the ecosystem buildout?

Yeah. Well, first it's great to see everybody here just coming off of Dev Day. We're really excited at OpenAI to like partner with all of you. Part of our strategy as Sam mentioned at Dev Day is that we really want to help build these future generation of companies that are AI native and help them find distribution, help them find product market fit, but also give them access to the same technology that we have whether it's the models or the underlying harness or the underlying platform. And so our go strategy and our goal is to like enable people to build really ambitious projects and companies and help them take off. And so to that end, you know, we're doing a couple of things that kind of illustrate this strategy. So one is we launched plugin extensions which allows you to, you know, use MCP apps to have kind of direct full pane access in the Codex app. And so that allows people to build very sort of powerful experiences are native to the Codex experience. And that's a great way to not just build into developer workflows, but also get a lot of distribution. You know we serve something like 35 million developers and further to that as Paul mentioned we are working on sign in with ChatGPT with companies and that really allows people to kind of further leverage our distribution especially when it comes to things like token sharing. You know users can log in with their ChatGPT account and be able to use parts of their allowance towards that and because we know inference cost is definitely top of mind especially if you're just getting started and your users might not kind of are still maybe play around with your product. And the last thing that we're doing more on the B2B side is this marketplace idea where you know companies can use parts of their open committed spend to spend on our marketplace products. And so these are all the different ways we're hoping that we can help companies kind of in this new era to like bootstrap off of what OpenAI is doing.

Yeah, actually I played around with the extensions and immediately had some of the team test it out and we could recreate basically the entire Supabase dashboard inside ChatGPT which is pretty amazing actually when you think of it. Do you think that maybe at some stage like a YC company could ever be built directly on top of ChatGPT?

Yeah. Yeah. And I think the thing I would say is like you know building a company and building a startup is like very difficult and sometimes the early stages especially like finding distribution. So I think that's definitely an area that we want to help with. But we think ultimately like developers should own their like end-to-end workflow right so they should own the pricing they should own the product experience and we just want to help you like accelerate and distribute your product and help you find product market fit. And so, you know, we're working with companies like Supabase, Figma, very well established companies. We're also working with companies like Magic Path. I was just talking to someone backstage about like how they were able to kind of like bootstrap their product into it. And this helps you like quickly iterate on that. So, I could definitely see like this is like one of a distribution channel, but yeah, I think ultimately developers should own their end-to-end workflow. I think it would be pretty cool if one day like an entire company is built and like someone doesn't even know how to code directly inside ChatGPT. It would be pretty incredible time.