每个想法一个数据库：Supabase 收购 Turso 豪赌月建数十亿库时代，两位创始人首次同台

先说结论

这是 Latent Space 对 Supabase 两位联合创始人 Paul Copplestone（CEO）与 Ant Wilson 的专访（依据英文转写整理，全部 39 段、0s–4598s 已完整读取；主持人 swyx 开场即声明利益相关——他是六年前 Supabase 种子轮的天使投资人，Supabase 也是该播客的第一个赞助商）。两位创始人此前从未同台接受过采访。整场对话围绕 Supabase Select 2026 客户大会的「Build / Operate / Scale」三大主题展开，但真正的线索只有一条：数据库的下一个用户不是人，是 agent——平台当前每月新建约 500 万个数据库，嘉宾判断这个数字将走向「每月数十亿」，为此他们发布了无超时的长时计算、重写的 Postgres 存储引擎与高可用层，并买下 Turso 来做「一个想法一个数据库」的小实例。与之配套的是一组反直觉的增长数据：模型变强后注册量暴涨，而通常会被稀释的激活率与付费转化率反而同步上升——因为从注册到激活这一步现在由 agent 一步完成。矛盾也在这条线上：PLG 收入天花板原本被两位创始人估算在 1–2 亿美元，AI 直接把天花板掀到了未知处；而 OLTP 数据库迁移「几乎从不发生」，所以 Supabase 的企业策略不是赢得迁移，而是赢得 day one。这与本站 9 月 24 日云栖大会「为 Agent 重构数据库」专场复盘中阿里云给出的判断互为印证：数据库的设计前提，正在因为用户从人变成 Agent 而整体改写。

一、Select 2026 发布了什么：给 Agent 造的三层楼

第一层是计算。Supabase 现有的 Edge Functions 基于 Deno 运行时、有两秒的执行上限，社区长期想跑分块（chunking）、嵌入（embedding）这类长任务跑不了。新发布的 Supabase Compute 是无超时、serverless 的完整容器计算，与数据库跑在同一私有网络、物理同位，可以直接建立 Postgres 连接，Rust、Python、乃至 agent 本身都能塞进去——Paul 类比它是「容器版的 Lambda」[360–480s]。

第二层是纵向扩展，两个数据库内核级项目同日发布公开测试版。OrioleDB 是 Postgres 传统 heap 存储引擎的 drop-in 替换，嘉宾称快 1.5–2 倍、彻底消除 vacuum 与表膨胀，过去一年被拿去跑了 PGRegress 全量兼容、Antithesis、TPC-C 每夜基准与 Jepsen 一致性测试，并转为附带专利授权的 Apache 2 许可——Supabase 收购了这项技术、买下专利后免费开放[480–600s]。Multigres 则是对标 Vitess 的「Postgres 版分片方案」，请来了 Vitess 原作者 Sugu 主导。他们的出发点是一个扎眼的发现：Postgres 生态里所有 operator 在特定条件下都可能丢数据，于是干脆从零重写整个集群管理层；嘉宾称已通过上千次顺序故障切换测试且零丢数据，完全开源，平台上先以邀请制提供。与 Vitess 时代最大的不同是「先做兼容、后做分片」——分片能力预计明年初落地，届时用户不需要改任何查询[480–720s]。

第三层最重：收购 Turso，横向扩展。嘉宾给出的算术很直白——每月新建 500 万个数据库已是常态，而如果 ChatGPT（节目称月活 12 亿）这类入口让每个用户、每个 agent、每个想法都配一个数据库，就必须做到每月数十亿个，「给每人一个专用 Postgres 集群，全世界的物理计算机很快不够用」[720–960s, 3360–3480s]。Turso 用 Rust 从头重写了 SQLite（因许可证问题 fork 为 libSQL），为单写者的 SQLite 补上了 MVCC 多写能力，用无盘、WAL 写 S3 的架构在一台服务器上跑数百万个库。Paul 特别指出，这条路之所以现在走得通，是因为对象存储的新特性——S3 的强一致性、S3 Express 一到两毫秒的写入——正在让对象存储变成「数据库底下的那个集群」；Turso 创始人 Glauber Costa 的重写博客则给出了通往 Postgres 兼容的路径[840–960s]。收购后 Turso 品牌保留、专注 SQLite，Supabase 将推出兼容全部自家库的小型实例 Supabase Spark：任何想法先开一个 Spark，跑起来后零停机升级到完整 Postgres，再一路升到 Multigres[960–1080s]。算力层面，Supabase 同时宣布引入新投资方 CapitalG，嘉宾坦言需要 GCP 与多云——算力短缺之下「我们和 AWS 谈了很多次，付更多钱、做更多承诺」[1560–1680s]。（本站查证补充：官方新闻稿称此轮融资 1.5 亿美元、GIC 领投，Turso 收购同日宣布，Glauber Costa 加入后任 Head of Agentic Services；播客内只提到 CapitalG 一家。）

二、增长机器：从 8 个用户到「被所有前沿模型推荐」

Supabase 的冷启动如今已成创业教材：他们本来准备了 Hacker News 上线，却被一个随机用户抢先发帖，帖子冲上 HN 史上最高赞之一。关键转折是把标语从没人理睬的「realtime Postgres」改成「open source Firebase alternative」——12 小时后爆帖，用户从 8 个涨到 800 个。当时每个数据库要吃掉 DigitalOcean 两台 5 美元 droplet，1 万美元信用点 48 小时烧光；进了 YC 后 AWS 给了 15 万美元信用点，他们在 YC 第一周手工迁移了 800 个库。DigitalOcean 因为「已用过小额信用点计划」拒绝批给他们 30 万美元额度的大计划——嘉宾笑称这可能是 DO「因过于严格而损失的最大客户」，而 DO 如今市值 160 亿美元[1320–1560s]。

增长手段则几乎是反营销的：meme。Ant 团队每周开 meme workshop、雇了一小组青少年帮忙，因为「要既懂技术又懂开发者觉得什么好笑，这种人很难招」；曾有人写了四万字的 Supabase 推特策略拆解发上 HN，被社区骂，Ant 把骂声截图发回自家推特——「你的恨意滋养我」[1080–1320s]。

真正的爆发来自 Ant 总结的「AI 三部曲」：第一部是 embedding 时代，靠 Andrew Kane 独立开发的 pgvector 扩展教育市场「存向量不需要再买一个数据库」；第二部是 2024 年底的 vibe coding 浪潮（Lovable、Bolt），团队曾激烈辩论要不要服务这些「玩具项目」，最终被「存储世界的数据」这个使命说服——「在你起步时在场，确保你永远不想离开」；第三部就是今年：模型变强后注册量陡增，而反常识的是，通常消费级流量涌入会拉低激活与付费转化，这次两者却同步上升——因为注册到激活由 agent 一步完成、摩擦消失，且这批用户的付费转化率高于传统开发者，而公司几乎没有营销预算[1800–2040s]。变现也在加速：过去是做完产品再接计费，现在 Stripe 在 agentic 层直接可用，嘉宾看到有客户同周内产生可观现金流、上线几天赚一万美元——正是那个案例让他们确认 vibe coding 不是 NFT 式的一阵风[1680–1800s]。客户画像随之改变：教师出身的 Magic School 创始人、没有技术联创也没有 CTO 的公司越来越多，「人人都是 builder」[960–1080s]。

swyx 用自己的 AEO 追踪器补上了最关键的一环：每一个前沿模型都把 Supabase 推荐为 integrated backend 的首选。嘉宾把这归因于运气加卡位——在 LLM 起飞前三四年就以「Firebase 的头号开源替代」存在，社区六年积累的博客、YouTube、Discord 问答、开源代码全部被模型吸收，「我们只是需要维持这个领先」[2040–2160s]。社区资产也被正式资本化：为了让社区参与融资，律师说没有合格投资者机制不行，他们反问「如果不投资、直接送股票呢」——最终划出 100 万美元股票赠予社区成员，第一位是 Discord 里六年回答了两万个问题（其中 1.3 万个在一小时内回答）的退休传奇用户 Gary Abbott[2160–2280s]。开源版本则刻意不埋任何追踪——他们不知道开源市占率，但有大药企主动找上门说「我们跑着你们开源项目的 100 个实例，能卖我们个产品吗」，于是把面向 AI 平台公司的 Supabase for Platforms（2025 年 12 月上线）重新打包成企业舰队管理产品 Control Tower[2400–2520s]。

三、销售与迁移：被掀翻的 PLG 天花板，与从不发生的迁移

Supabase 以 PLG 著称——嘉宾称每届 YC 批次 60% 的公司在用，榜样是 Stripe（「唯一顶住十年上移市场还保住开发者爱的开发者工具」）。但他们的销售层值得所有 SaaS 公司抄作业：每周约 1000 个产品触发（扩容、报错、消费阈值、重点 logo）触发外联，约 500 人回应；不回应的那 500 人天然构成对照组，月环比增长 25%；被销售「上电话帮忙」过的账户月增 125%——多出来的 100 个百分点就是销售提成的唯一依据。销售的任务不是推销，而是拿着 AI 根据用户流量模式生成的脚本去帮人解决问题[2520–2640s]。

迁移则是整场访谈里最冷酷的判断：OLTP 生产数据库的迁移「几乎从不发生」，因为每一分钟停机都是直接收入损失、双库并行又带来 split-brain（脑裂）风险；历史上所有以迁移为主业的数据库公司都失败了。所以策略是「day one 落地、day 一万留住」，企业市场的 greenfield（企业内部产品团队人手起一套新栈）反而是最肥的新场景。Multigres 留给未来想搬 Oracle 的巨兽——节目引用称一年前 Oracle 按收入只有 5% 的负载在云上；一位董事会成员（转写名不清晰）的论点是 Supabase 不只替代 Firebase，更是「新 RDS」、终局去掀 Oracle 的桌。嘉宾的回应很克制：当然会试，但先聚焦进入企业[2640–3000s]。被问到 Databricks 两位联创（本播客此前专访的 Matei 与 Reynold）宣称解决 HTAP 时，Paul 表示更看好 DuckDB/Duck Lake 路线（「分析界的 Postgres」；嘉宾并称 DuckDB Labs 近期被 AWS 收购——此说法本文未核实），但立场是 OLTP 到一定规模必须分片、分析用对的工具分开做，「把两者硬捏在一起未必有意义」[3000–3240s]。

战略层面最坦率的一句话是关于天花板的：创业时他们以为 PLG 能做到 1 亿美元、最多 2 亿美元就要换打法，「因为 AI，天花板被掀掉了，我们不知道掀到了哪里——是 10 亿还是 20 亿」。年初 offsite 定下的「疯狂野心」收入目标，有人担心团队会因达不到而失望，结果四个月就完成了[3360–3480s]。当前 P0 是赢得各家前沿实验室与模型伙伴（已合作 Gemini、支持 Sign in with ChatGPT，希望成为 ChatGPT 应用分发的默认后端之一）、继续 PLG、以及拿下企业新负载；Temporal 式持久工作流也因 2 秒超时的解除而解锁——此前社区想在 Supabase Functions 上建工作流引擎全部失败[3240–3360s]。

四、代码优先，与两个焦虑

给 agent 的最后一块拼图是开发体验的范式转移：Supabase 从 dashboard 公司走到 headless，今年的重心是 code-first、Git 原生。传统 Postgres 工作流是 migrations 文件夹——每次变更追加一个文件的「历史日志」，agent 面对上千个迁移文件只能重编译或起库内省才能猜出当前表结构，太慢。新发布的 PG Delta 库让 schemas 文件夹成为数据库的完全声明式状态（表、策略、注释全在文件里），「agent 主要在代码上操作，它们不想外呼任何东西」[3480–3720s]。Paul 的愿景推到极致：对手机上的个人 agent 说「我要做 X」，一秒后应用上线——不再需要是工程师。

两个焦虑也都值得记录。Ant 担心 mode collapse：软件行业的进步靠 flame war 维持多样性、让最优解胜出，如果 agent 让所有人变懒、全部收敛到一种「正确的」构建方式（「他们全都会用 Supabase，太棒了，但是……」），行业可能锁死在局部最优。Paul 认为恐惧有效但不可控：低门槛的 casual builders 会收敛到均值（也就是模型推荐的那一家），高技术的人会继续抠细节并向下渗透；他顺带下了个暴论——「平均水平的大学可能完了」，顶尖自学者永远有出路[3720–3840s]。第二个焦虑关于开源本身：嘉宾认为 Rust 重写浪潮是真实机制，大多数开源工具会塌缩成少数 Rust 赢家，连 Postgres 若被重写也只会剩一个 Rust fork 胜出；Vercel 的 Malte Ubl 提议留一笔钱把所有依赖的 C/C++ 层重写成 Rust、相当于「开源世界的一次性升级」——Paul 说 100% 支持，但预测不会发生，因为人们爱自己动手[4080–4320s]。

AI 内政数据也少见地透明：公司去中心化到各团队自定 AI 编码政策，最近才开始围绕成本收拢。swyx 给出的市场锚点是普通人每月 20 美元、平均员工 200 美元、OpenAI 五十分位员工 3000–5000 美元、顶尖者数十万美元；Paul 给出的度量是 token 花费与人力成本之比——多数公司 0.1，可以安全升到 1，超过 1.5 大概率有麻烦。Supabase 自身是每月 30 万美元、450 人，分布极度偏斜（两三个重度用户贡献大头）；公司内部有使用排行榜，上榜者会有点羞愧——swyx 立刻反驳说焦点错了，该看的是端到端解决了多少流程、把多少长周期人工问题压短，而不是花了多少钱。作为全异步公司，Supabase 把一切决策都记录在案，如今正拿这些语料构建「公司 harness」，让 AI 把整段公司史沉淀成决策原则[4200–4440s]。招聘上约 50 个开放岗位、全球远程同薪，最缺 SRE——swyx 断言 AI SRE 至今是 agent 创业最难攻克的类别，Paul 认同：「造软件勉强算解决了，让东西一直跑着完全是另一头怪兽」[4440–4598s]。

行业机制与读者启发

把账本串起来，至少四条链值得带走：

1. 「每 agent 一库」的经济学重写数据库行业。变化：模型变强→注册即激活（agent 代劳）→非技术 builder 涌入→建库量从 500 万/月冲向数十亿/月。机制：专用 Postgres 集群的物理成本不可扩展，文件型数据库（SQLite 重写 + WAL-on-S3）+ 小实例（Spark）+ 零停机升级路径成为唯一解。二阶影响：数据库的计价单位从「公司」塌缩到「想法」，对象存储的新特性变成数据库内核的地基。观察指标：ChatGPT 等入口是否默认给每个 artifact 配库、Spark 与 Multigres 分片（嘉宾称明年初）的落地、Supabase 月建库数与 attach rate。启发：基础设施的胜负手正在从功能清单变成「入口的默认选项」——被模型推荐就是新的分发渠道。
2. AEO 是提前三四年埋下的复利。机制：开源+社区内容（博客/视频/问答/GitHub as CMS）全部可被抓取→被前沿模型固化为「标准答案」→agent 生成的代码自动选择你→增长自我强化，营销预算近乎归零。启发：agent 时代的内容策略是「让模型读得到」，封闭社区与私有文档等于放弃分发；后来者（如节目提到的 Resend）只能靠 AEO 实践追赶。
3. 不可迁移性是数据库最深的护城河。OLTP 迁移的停机成本与脑裂风险让「赢得迁移」近乎伪命题，可行战略是「赢得 day one」并陪伴到 day 一万；企业 greenfield（内部人人开发）取代迁移成为新单来源。启发：评估任何数据库/基础软件公司时，与其看迁移工具，不如看它在「新建项目第一分钟」的占有率——Supabase 用 60% YC 批次渗透率与产品触发式销售（对照组增量 100 个百分点作提成基准）把这件事做成了可复制的机器。
4. AI 编码开销有了可用的预算锚。token 花费:人力成本比 0.1→1 为安全区、>1.5 预警；且分布极偏，管理少数重度用户优于全员限额。配合「看端到端流程解决量而非支出」的视角，这套口径可直接搬进任何团队的 AI 政策讨论。

归属与转写说明

本文事实与引语均出自本集英文转写并逐段核对时间戳；swyx 为 Supabase 种子轮天使投资人且 Supabase 为播客赞助商，其「0 到 100 亿美元估值」「每个前沿模型均推荐 Supabase」等说法均为主持人口径（前者与外部报道的 Series F 后 105 亿美元投后估值相符）；Multigres 千次故障切换零丢数据、每月 500 万新建数据库、60% YC 批次渗透率、30 万美元/月 AI 开销等数字均为嘉宾自述，未独立核实。DuckDB Labs 被 AWS 收购、Oracle 5% 云负载等为节目转述。「Postgres 用 Haskell 编写」一处为转写或口误（Postgres 实为 C 语言编写），附录保留原文。本站 9 月 24 日云栖 2026「为 Agent 重构数据库」专场复盘与本期互为印证，可对照阅读。

附：转写疑似错误与校正

以下已确认项已在文末《转写原文（修正版）》附录中机械替换，正文均已采用校正后写法：

• Superbase→Supabase：56 处，系统性同音误听，已按官方拼写全局校正。
• multi-gress / multi-Grass / MultiGrass / Multigrass→Multigres：合计 10 处。官方项目名为 Multigres，已按 Supabase 官方博客校正。
• Dino→Deno：2 处。Edge Functions 的运行时为 Deno。
• Globa→Glauber：1 处。指 Turso 创始人 Glauber Costa（其余多处已正确识别为 Glauber）。
• Suku→Sugu：1 处。Vitess 原作者 Sugu。
• Live SQL→libSQL：1 处。Turso 对 SQLite 的 fork 名。
• Capital G→CapitalG：2 处。Alphabet 旗下成长基金。
• Mate and Reynolds→Matei and Reynold：1 处。指 Databricks 联合创始人 Matei Zaharia 与 Reynold Xin（本播客此前专访嘉宾）。
• Versell→Vercel、Malta from→Malte from：各 1 处。指 Vercel CTO Malte Ubl。
• recur center→Recurse Center、Pyongji→PLG、paperclip maxing→paperclip-maxxing、signing with ChatGPT→Sign in with ChatGPT、Danji→Dang（Hacker News 管理员）、Loveable→Lovable、Oriol DB→Oriole DB：各 1 处。
• 保留原文待核：Karen from Co2（疑为某投资机构人士，未能确认）；Angelico（疑为早期员工人名）；「Postgres…written in Haskell」（疑口误，实际为 C）。

转写原文（修正版）

[0s - 120s] Hello, it’s me again. I hope you’re enjoying these little episode intros that we’re doing. Hopefully, it gives me a little chance to talk to you guys about why we’re doing some of these episodes and what you should look out for in the interviews, so you get more out of the interviews. We’re also adding overlays that you can see pop up to keep it visually interesting, to explain things that maybe if you’re newer to the industry, you don’t know, because I don’t have time to go over every single thing while we’re having interviews. So I was at Supabase Selects recently, which is the Supabase company conference, and there’s a lot of stuff to cover. In particular, I think I should share that I have a very close relationship with this company. I was an angel investor in their seed round six years ago, and they were my very, very first angel investment. They’ve done super well. They went from zero to ten billion in valuation in the last six years. It’s a fully remote, open source company, which is enormous, and they’re pretty much becoming the standard for hosting Postgres. So I want to break down why they’re making tick. I also want to see why did it so well in my AEO ranking because it’s not it’s not a given for sure, and there’s a lot of companies that are fighting for what it means to build databases for agents. They were also, I think, our very, very first sponsor for AI Engineer, the very first AI Engineer in 2023, and they’re now going to be our first sponsor for Latent Space, which because we’re open for sponsorships and you know who else to to do this with with companies that and people that I’m familiar with and trust and can explain very well to to our audience. And so the main things I wanted to cover they have they have a whole recap here and on their YouTube, which is very well executed and all that, but they have these three themes of build, operate, and scale. I think the announcements are very much what I kind of look for in a company conference keynote. So build is basically how they want

[120s - 240s] To improve post the Postgres experience for coding agents to set up, and the the two that that really shot out to me is what one is is very simple one is which is that starting Supabase without Docker that that is the the less weight I can I need in order to start up basic processes to interact with the the database the better and obviously I can scale it up to to a full VM in in the future but the second thing is Supabase compute where you run compute next to the database I think collocating that is super easy I think this is honestly super underrated I think is maybe underselling what it potentially could be your app having an MCP server from Supabase is really good and but declarative schemas is so important right but like you want declarative schemas rather than the standard SQL paradigm of set up a schema and then migrate migrate migrate which is something we cover in the the the podcast like if you you want everything to be in Git as source of truth so that your agent can crawl it um and figure and set up and fork and whatever from there it seems so simple but really when Postgres was not designed to do this uh you have to kind of retrofit developments on top of onto a you know forty year old database and really I I kind of see Supabase’s momentum now as doing the last mile like the the really like frontier of Postgres development for agents to really use them super well the beauty of it though is that it’s not actually about agents it’s like we just needed this the whole time so but humans also benefit and I I really like that I don’t like doing own doing things only for agents to be happy so then the second part is operate operating so that is mostly just about giving more context really whether it’s more logs more checks more connections markdown files for your SQL that’s super cool knowledge and skills they every year they ship

[240s - 360s] Some interesting pipeline work from like you know Stripe to to to other sort of integrations, and I think the sort of general ETL problem, as you get further and further in your AI engineering career, becomes you know more and more part of the data engineering stack. But now Supabase has their own first party solution. You can use a mix of both, like whatever. But sometimes it’s nice to have everything in one. The last part is is perhaps the most complex and you know at scale thing. This is why Supabase is engineering branding to prototype to petabyte, and really they’re going after more and more scale, obviously because the customers are growing. And so announcing a full V1 of Multigres, which is their their sort of port, I guess, of Vitess for for Postgres with the Vitess guy, which is enormous in the database world. If you don’t know what Vitess is, you’re losing out. You you need to know. You’re you’re watching this on YouTube on a Vitess website. Um, Oriole DB and DB. So like, there’s a lot to go in there, and honestly, you can see my connection with the with the founders. I think this is the first interview ever that the two of them have done, and I make reference to that and try to view their chemistry and show show you what it’s like to discuss and run a ten billion dollar database company. Enjoy. Okay, this podcast has been six years in the making. We’re excited to have Copeland and Ant in the studio. Welcome, guys. Thanks. Thanks for having us. We’re recording this ahead of Supabase Select, which you know it’s your it’s your big customer conference, and we’ll release this after the the conference. But I just want to sort of celebrate the journey that you guys have been on. I’ve seen you guys since you guys finished YC, and you were like in that place in Singapore where you were sort of celebrating things, and I you know I I met you.

[360s - 480s] For the first time, and I was like, “What is this like hot database company that like got soft launched on Hacker News by like you know some random user sometime?” Anyway, congrats on all the the success. What are you announcing? The headlines at Select. Let’s just get right into that. Yeah, yeah, sure. So there’s quite a few headlines. We’ve got a lot to cover. The main ones would be starting off with compute. So we offer a product called Edge Functions, and Edge Functions are powered by Deno, and they have basically a two second limit. What we’re finding is that, well, what we’ve heard from our community for a long time is that they want to run much longer workloads. They want to do things like chunking and embedding. So tomorrow we’re announcing, and by the time this comes out, super base compute, which is you can run anything. It’s long running. It’s serverless. It is running the same private network as your database, so it’s collocated, has very good latency, so you can run Postgres connections directly from compute, and you can run anything inside it. So it’s no longer constrained to just Deno. You can use it with Rust or Python. You can run agents inside it. It’s basically just a full compute instance. Let’s call it the comparable offerings in other clouds that others might be familiar with. Would this be? Yeah, something like a Lambda function, but the container type Lambda function. Okay. You can run a full container basically. And then there’s the other stuff. Yeah, and then we have, well, three innovations on the database space. So the first one, which we talked about last year, which was Oriole DB. Oriole DB, we’ve basically put it through the ringer in the past year to make sure that it is rock solid and ready for the Postgres ecosystem. The three innovations are basically performance, scaling up, and scaling out. Postgres touches on, sorry, Oriole DB touches on performance. It is a drop in replacement for the the current Postgres.

[480s - 600s] Storage engine, which is Heap, and it runs about 1.5 to two times faster, and you don’t have to change anything else. It’s just completely compatible. It completely removes the need for some of these background tasks like vacuum and bloat, so it’s actually very efficient for your database as well. And basically, the innovation that all the work that we had to do this year was put it through PG Regress, full compatibility with Postgres antithesis. We put it through TPC C nightly benchmarks and Jepsen to make sure that it basically can never lose data. So we’re releasing it tomorrow in full beta, and we also made it Apache Two licensed. It comes with a patent, and the Apache Two license covers the patent. So we actually acquired the technology, continue to develop it, and then we pay for the patent and are now giving it away for free. One thing that you mentioned in passing, which I still don’t, I can’t get over, is that you tested every operator and you said every operator drops data in some situation. Well, so this is for the second, the second one. So scaling. So that’s that’s that’s Multigres. Yes, so Multigres is the second big announcement. Basically, we looked at the Postgres ecosystem and we looked at all the operators. An operator, for those who aren’t familiar, when you run Postgres, you start with a single node, but then with almost any database, you want to run multiple nodes, and you want things like failover, you want it to manage backups. So usually, you have this thing called an operator which can run the entire cluster for you. So there’s quite a few operators in the Postgres ecosystem, and what we had found was that under certain conditions, every single one of them could lose data, and so we decided with Multigres to do a ground-up rewrite of the entire structure of a of a operator. And so Multigres is essentially, while our initial goal is to become give sharding to the Postgres community, what has turned out to be is this entire operating system, and we actually ran it again through very rigorous testing, and we’ve done a one thousand.

[600s - 720s] Thousands sequential failovers, and it didn’t lose any data. And we’ve tested it in basically every way we can, clobbering it to see whether it will ever lose data. So we’re very confident now in its stability. And so we’re releasing that one as well tomorrow. It’s completely open source. It will be on our platform for customers and invite only. So people who are running serious workloads can come to us, and we’ll start helping them to scale up. Is this the full completion of Multigres being fully sort of parallel to Vitess, or is there still something left to go? No, actually, yeah, it was quite interesting. So Sugu originally created Vitess in for the MySQL ecosystem, but specifically for sharding. And actually, when he came along, he said, “Well, the number one goal that we want to do for this time, because we’re always catching up on compatibility when we use Vitess, you always had to change things as you move to sharded. So change some queries. So he said, I want to focus only on compatibility first. And so the way we’ve designed it is in such a way this ground up rewrite is specifically so that we know when we release sharding, you actually won’t have to change anything for your database. You’ll continue to run the same queries, and Multigres will just be able to handle it. Zero changes to your code. I mean, that’s incredible vision, and the fact that you’ve been able to do it in two years. That’s one year. One year. So we haven’t released sharding yet. I’ve seen the early prototypes and the designs for how we’re doing it, and it should should some of it should land by probably early next year, depending on some of the things that are happening on our platform. We’ve got a lot going on, but but we’re very confident, and we’re we’re happy with the progress. It’s it’s been pretty good. Yeah, I mean, I think this is the last piece for the total domination of Postgres. Yeah, right. Yeah, that’s and for those who don’t know, you know, look up Vitess. Powers YouTube. Powers what else? GitHub. Everything. Yeah. If workloads were

[720s - 840s] Ever to shift away from MySQL, you need this to to Postgres, and that’s then for Supabase to win. And hopefully, it’s not just for Supabase customers, right? Like it’s fully open source, community thing. Anyone who’s who’s running Postgres at scale should be able to use Multigres. Yeah, I’m sure. Like every coalition, every company that’s involved in Postgres in some way is contributing to this thing, right? Because we all want this. Yeah, yeah, we’ve got a whole design partner program, so we’re working with like the Booz Allen, we’re working with Postman, we’re working with Perplexity. So yeah, lots of customers coming on board. That a lot of people need it. They’re running Postgres at scale, and they need something to help them scale up. Yeah. Third. Third one is yeah. So this one’s a big one. Scale out. At the moment, we launch about five million databases on our platform every single month, and kind of the future where we know we’re going, we think that we’re going to have to launch billions per month, and so scaling out is a whole different beast. So we decided that we would have to look at some new architectures and people within the space, the agentic database space, and there’s no other leading database provider who does agentic well than Turso. And so, actually, tomorrow and when this is announced, it would have come out where we have announced that we’ve acquired Turso to help us power agentic databases. Yeah, that’s an incredible. It’s also like they’re they’re primarily SQLite based, but it doesn’t really matter, right? Like it’s it’s it’s more about the architecture of like I guess I don’t have the word to describe how basically like broadcasts is that the word for for scale out, right? Like there’s the idea for them scaling SQLite was that they would have like a single writer and like multiple readers. Yeah, so so SQLite itself it’s only a single writer. It’s a file format, so generally it’s not like solving MVCC for exactly exactly. So then they built this.

[840s - 960s] Turso architecture, which basically builds MVCC for SQLite, so that you can have multiple writers. Yes, and because SQLite has a weird license, they had to fork it. They had to fork it. They originally started with libSQL, and then they they came along and they did this other really cool architecture. And actually, now the architecture actually was very commonly discussed a few weeks ago, while on S three. So some of the innovations in the database space are actually coming out of what’s happening in object storage. So object storage has added a bunch of new features, which basically mean that you can start using it a little bit like a database. And because object storage itself is, I think, it’s eleven nines of of data durability, which is not reliability, but whatever. Yeah, not reliability, but it it gives you what you need for for basically what you would typically have for a cluster of databases. It’s kind of like your cluster underneath, so you can start doing some cool things like, yeah, there’s quite a few popular databases now or data use cases that are building directly on top of object storage. It’s got some limitations in our worldview. It’s probably good for these smaller use cases in terms of transactions, because when you’ve got a transactional database, you’ve got to do a lot of reads and writes. And so in this case, you probably don’t want to be doing something at massive scale on this, and that’s why we have Multigres. But for these, what we’re seeing where we need to get to these billions of databases, what we need them to be is a file format. And so that’s where SQLite was super interesting. It’s dominating, and actually, the thing that really piqued our interest, and I reached out to Glauber. I said he released a blog post on how they’ve done their rewrite. Basically, makes the we have a pathway to get Postgres compatibility with their file format. So we’re acquiring them, and we’re actually going to keep the Turso brand. So Turso is going to focus on SQLite, and then we’re going to introduce this new smaller instance type on Supabase called.

[960s - 1080s] Supabase Spark, and it will be compatible with all our libraries. And you can have one database for any idea, any prototype that you want. And when it takes off, then you just upgrade to full Postgres databases, all the way up to Multigres. I know you’ve been working on this for a while. This is the dream, right? Yeah, yeah. There’s been both scaling up and scaling down has been one of the things that we’ve been trying to figure out how to do. Yeah. And it’s really when some of these innovations came along that we realize, oh, okay, we can do this. You know, you’re going to five million a month. Let’s say you see on the trajectory of billions per month. One of the secrets is they’re actually kind of small databases. Yeah. Right. Like these these things are tiny. They’re micro apps. Like yeah, no, like I I don’t know if you have any insights on the on like what yeah, I mean, until they get traction, right? And that’s the thing is like once you hit the front page of Hacker News, you need to know that you can go far beyond that. Um, and so the whole idea with with all of this was we need to make sure we’ve got a really smooth pathway to migrate between the backends, like zero downtime migrations. It’s like we, it’s just like a need to have because like we see now that there’s a lot of non-technical builders who are building like whole companies, right? We have the Customer Magic School, and the guy was like a teacher, right? And he saw all these like inefficiencies in teaching, like teachers spending time that on on tasks that could be automated. And so now you have these startups that start without a technical co-founder, without a CTO, and that’s not like isolated incidents anymore. That’s like becoming more everyone, everyone’s like a builder now, um, and that’s why we see like the growth we’ve seen over the last 18 months is crazy. Yeah, but but it still feels like early, and I think um, there’s a much larger market of almost like consumer-like builders, right? People inside companies, people who want to launch their own startups, which is gonna mean a.

[1080s - 1200s] Lot more databases, which, like we said, like if we give everyone a dedicated Postgres cluster, it’s probably you know we’ll probably run out of physical computers in the in the world pretty fast. Which is basically what’s happening. Yeah, I mean, like we’ve faced it throughout this year. We just our growth has uh has been uh one of the things that we’ve had to deal with in terms of capacity of compute. Yeah. So, congrats. Also, I will observe that I feel like Glauber is also a meme lord. Yeah. Well, that’s one of the things. Right. I mean, like, come on. Yeah, he’s amazing. So, for those who don’t know, the the person behind the Supabase memes is this guy. Yeah. That you know, low key, low key a killer. I always say, and well, Glauber also. Yeah! Yeah! Yeah! Big time. Any, I don’t know if you guys exchange notes on like what’s funny. Not yet. No. Really? Did it ever came up? We’re gonna give him access to the Supabase Twitter account for sure. My God. I could do with some help. Yeah. Yeah. Wait, is it still you? We’ve got a small team of teenagers now who help me out. You do workshops, right? Yeah, but it’s we do a weekly workshop, a meme, basically weekly meme workshop. But it’s hard to hire for because you need to understand the tech and understand like what developers find funny, basically, in order to do that type of marketing, right? Yeah. Actually, you you are also low key like meme lord. I’m not as funny as you. You’re really, really funny. Where’s there was one with like a seagull and you were like standing on top of Supabase turtle, standing on top of Postgres, I think. Yeah, but a seagull, standing seagull, riding a flying seagull, and it’s like, my God, yeah, I can’t, I can’t find it right now. But and this is all like deep Supabase history, but like you know, there there was a time when like those things were just like it was so good, people wanted to be like you and they couldn’t, and it was your moat, like memes. Yeah. And there was some big companies trying to run memes off their Twitter account.

[1200s - 1320s] So I won’t name any names, but like very large organizations. But yeah, it’s it’s like I said, it’s hard to hire for the guy who did like a forty thousand word essay on breaking down our meme strategy. Someone studied our Twitter strategy actually really early on and posted it on on Hacker News. Yeah, on Hacker News, and and that was funny because they recorded the strategy in a way that we hadn’t committed to paper yet. So then when we onboarded new marketing people, we were like, “Here’s the strategy.” It was written by someone else. Yeah, and of course Hacker News hated it, and then they were commenting on it, and I found out and took the the first comment. This guy, this guy, yeah, yeah. Learnings from four months of super base feed. He just looked at your work. When was this? Twenty twenty two. Okay. Yeah, yeah, yeah. Wait, I I mentioned it. Ooh, there you are. So he just broke it down. He broke it down, and then Hacker News hated it on it, and so Ant took a photo of them shedding on it and posted it on our Twitter again. Your hate just fuels me. What is this interesting article? Yeah, okay, so I commented. Yeah, yeah. There was like a lot of our growth was thanks to Hacker News. I mean, in the early days, I just yeah live on there, and so we should talk about that. What deal with the devil do you have to do with Dang? Ah man, we we’ve been schooled by Dang like many times, like for for launching too many things in a week, basically. And he’s like rightfully paranoid about the association of Hacker News and YC. So he kind of like if something happens, he kind of wants to throw us under the bus so that people know, oh, we’re not doing this for YC customers. We’re an independent site. So he’s been helpful to make sure that we we don’t smear the name of of YC or Hacker News. I mean, at this point, you don’t need them, but like for sure, I think Dang does a Dang has super high credibility. No one, no one really like you know questions him, but I do.

[1320s - 1440s] Think like you know. You guys innovated the strategy of launch weeks, and for a while, I think that was one of the launch weeks. I think four or five, where every single launch was like number one or page one on Hacker News. I got told off so badly for that because I tweeted that proudly. I was like, “Oh, here we are!” And then I got told off because we were like, “It basically looks bad because because like suddenly this YC company is like dominating the front page of Hacker News. It looks like it’s a bias. I’m like parading the fact that you’re on the front page, yeah, yeah, yeah, which is true. Like, so like tip to anyone: never screenshot the fact that you’re on the front page of Hacker News and put it on Twitter because it’s it does look like quote and and to be honest, it it was gloating. So so it’s a fair fair call out. Yeah, yeah. There’s all that which like I would say I was considered that somewhat ancient history now. You know, it’s been a few years since since this is a relevant thing. But for those who don’t know Supabase history, these are the things that you must check off as like the tour of things. What else? I mean, I think the the top post there is interesting because this is the launch post. Yeah, but but it was someone else who launched us. Like we went ready. Yeah, yeah, yeah. We went ready to be launched on Hacker News, and you didn’t consider yourself a Firebase alternative. Oh yeah, so that was the day that we changed the tagline. We had was the original tagline. It was real time Postgres because what had happened was I wanted like we we were like oh let’s build a Postgres company, but in my previous company I had to migrate from Firebase to Postgres, but I needed a real time feature, and so I ended up building this real time engine on top of Postgres, and so we thought oh that’s the killer thing like it’s getting some open source traction, this real time engine, it’s kind of cool, so we were like oh real time Postgres, no one cared, no one cared when we had a website, and so like we’re like let’s change it to open source Firebase alternative, knowing that that was the reason why I switched, and it was I think only twelve hours later or something like that that this article went up. Yeah, still the top of all time, and at the time we was running.

[1440s - 1560s] On top of DigitalOcean, and every new database was two droplets, so two five dollar a month droplets. Why two? Um, one for the database and one for the APIs. Right, because we because we wanted to upgrade the APIs and a handful, and we only had a handful of like test users at that point, and then all of a sudden, I think we only had eight users. Yeah, we went from eight to eight hundred on that that launch eleven. Yeah, and then we burned through. I think we had like ten k of DigitalOcean credits, which we just burned through in basically forty eight hours. Um, and then we just got into YC, so AWS was like, “Oh, we’ll give you, you know, whatever it was, one hundred and fifty k credits if you migrate to us.” And so we spent the first week of being in YC migrating eight hundred databases to a different cloud. Which you know, if you’ve ever migrated one database, you know how painful it is. It’s like migrating eight hundred is not how you want to spend your first week in YC. Do you remember that we could have been on Digital? Like, basically, we should still be building on DigitalOcean because when you get into YC, they have this credits program, like huge number of credits on DigitalOcean at the time, and we’re like, “Hey, can we have these credits?” Because we’re like, we’re blowing up here, and they said, “Oh no, you’ve already used the ten thousand dollar credit program. We can’t give you this other one for three hundred thousand.” So we’re like, “Well, we have to migrate to AWS,” and so the biggest lost opportunity of DigitalOcean being too strict. Yeah, I know our bills with AWS now. This is like probably one of their biggest customers ever that they lost from being too strict about that. Because it was COVID, it was a time when everyone was worried about like what’s going to happen. True. So I think they were like, “We don’t want to overextend ourselves.” Um, it’s fair. Yeah. Yeah. So it was like totally fair at the time, just given the um the way the world was looking. People made many irrational decisions during COVID. Yeah, but you never know. I was going to say you might be worth more in DigitalOcean now, but then somehow DigitalOcean has also like.

[1560s - 1680s] Gone on a super tear. Ah, look at this! Because computers tripled in the last year. Wow, that’s cool. So what are they? Sixteen. They’re sixteen billion now. Billion, yeah. Perfect. Okay. And like, and like, okay. Well, I guess there’s a shortage of CPUs. Yeah, there’s a shortage. How are you guys experiencing it? We literally, I mean, we’re up against runways all the time. Where like we meet AWS like multiple times. Is there a way to spike when you have a spike? What do you do? Like you, you just have agreements with people. Yeah, we’ve got to like plan. You just pay very closely. We we pay more. We partner with them. And in fact, tomorrow as well, we’re announcing that we’re bringing on a new investment partner, which is CapitalG. CapitalG basically has access to the Alphabet ecosystem. Good for us on both sides. Like we now have to consider a multi-cloud strategy. We need GCP. We need GCP. Well, we need more compute basically. So GCP is a very obvious choice, and of course, we want to partner with all the AI labs as much as possible. And so they have a suite of products. We work with them already on Gemini, and we want to make sure that we’re embedded deeply into all of their products. And that’s another thing where you’re mentioning how so much of the database ecosystem is being shaped by block storage and all these innovations and all these things. Clearly, AWS is is is the leader there. It’s hard to be multi-cloud if you’re gonna use GCS as like a swap for S3. Yes, as long as they’ve got the features. Actually, I don’t know if their object storage has the all the features, but I’m sure that like whatever S3 do, others follow. So I I still remember. I think like three years ago they introduced like strong consistency. Yeah, that’s the innovation basically. That right, that helps. Yeah. And they just like they did it for free and they just rolled it out to everybody. Yeah, yeah. It’s like it’s live now. What? Yeah, yeah. And then S3 Express as well. That was a big game changer because why? Well, basically now what you want to do is like you typically write to a local drive and then you need to batch it to something more durable, and that batching process. Um, and so the write times to this.

[1680s - 1800s] A one to two milliseconds, and so before you can guarantee a write back to your client, you basically need to batch it to something that’s durable. So this one’s durable, not as durable as S3, not eleven nines, but durable enough that you can. It’s ephemeral durable. Yes, exactly. And then, then in the background, you take you take you use this kind of as your cache, and then you move into S3 in the background, which is cheaper. Do we need Redis anymore? Ah, yes. Yeah, you still need Redis. Like this is nowhere near fast enough. You need like basically your cache layers are either memory, NVMe drive, local attached S3, their equivalent, and then S3. Yeah. Normal. Amazing! Amazing. That was a little bit of data. Like we we jumped around quite a lot. Sure. Yeah. Clear business memory. A few more things that we’re going to talk about. You your slogan was building a weekend scale to millions. Now we’re prototype to petabyte, which is excellent, and really it is reflective of the evolution in scale that you guys are doing, right? Yeah. Do you have anecdotes on like let’s say early superbase versus now? How fast are people scaling when they when they start a thing? Yeah. Well, the big thing is, I think how fast people are monetizing. Oh yeah. At the start, it was like you choose your database, you build your product. At some point, you add in billing. Now, because you can add in Stripe, like at the agentic layer, it’s like we see customers starting a project and within the same week, like generating serious cash. Yeah. And and in the early days of vibe coding, it wasn’t obvious to us that this is something that’s going to stick around. This is going to change the way software is built. But as soon as we saw someone in and like I think it was ten thousand dollars within the first few days of launching their product, we were like, wow, this is this is real. People are making real things that generate real money, and so we knew we had to lean in in a way where there was waves we’d ridden.

[1800s - 1920s] Successfully in the past, like when NFTs were huge, we leaned in a bit and we added like signing with Ethereum and signing with Solana, but we didn’t dedicate like tons of dev time because everyone kind of knew it was going to go away at some point. And making that decision for for vibe coding was like, you know, we we discussed it a lot as a team of how much do we lean in, and it was a time when we knew we needed to go slightly more upmarket. Like our biggest customers were like stretching the limits of of what we had at the time, and so we knew we had to then just do both. It was like you know, innovate on the on the small like prototype stuff and innovate on the on the much larger side as well. And then you just need more people for that. Sorry, that one’s funny because like on the number side, basically for Supabase, there’s been three chapters of AI. So the first chapter was embeddings. I think we were on Supabase Vector, yeah, which I have now transcribed and it will always. We we should probably update this because yeah, yeah, this is the only talk you’ve ever done at AI. Yeah, we did this talk. Basically, all these embedding databases were coming out, vector databases, create the vector, and so we were pushing the fact and you can use Postgres as a vector database. And Andrew Kane, a completely independent guy, has developed this awesome extension. And we’re like, okay, trying to educate the market. Postgres can kind of do anything. You don’t need another database if you’re going to store your embeddings. So this was chapter one, and it was it was a really a good growth driver for us, and also good for the Postgres ecosystem. Just letting people know now there’s a lot of innovations and and embeddings. What TurboPuffer, for example, are doing, they use a lot of the innovations that Turso are doing, and I think it’s a phenomenal use case for that type of stuff. So that was chapter one. Chapter two was like the vibe coding wave, whereas Lovable, Bold, all of these ones coming along. That was end of 2024, and that’s where we debated a lot. Hey, do we really want to be there? Do we want to be

[1920s - 2040s] Servicing these, do we even want to have our own vibe coding type platform on top of Supabase? But in the end, like our mission is store the world’s data, and to do that, we based on our tagline, it’s like, be there when you’re getting started, make sure that they never want to leave. And so we saw people were getting started; they were doing toy things, but still, it fit our mission. We just had to believe that over time these tools would become better. And then the third one, which is the like crazy numbers, started this year. The models just got better, basically, and then we started seeing our top of funnel, our our sign up rate start rapidly increasing. But usually, when this happens, you’re pouring a lot of dollars into marketing. We actually barely spend any dollars on marketing, and most of it’s just memes and things like that. So here, I got one of your charts. There we go. Yeah. I mean, all your charts look the same, but because they’re just like exponentially, you just keep changing the crazy thing about this is is often when you get like more consumer like traffic in the top of funnel, your activation and conversion to pay goes down. Yeah. But both of those things went up. Started going up quite rapidly as well. Yeah. Because of the how do you know activation and conversion to pay? Oh, your it’s super basic. Our metrics, yeah, our funnel metrics. Okay. Um, and and the reason is because the sign up to activation, the agent does it for you. Yeah. Like in one step, so it’s basically it’s almost 100 percent. The friction’s gone. Yeah. Um, and so those users then were converting to pay at a higher rate than our traditional developer user. Okay. I mean, excellent. Great. Yeah. I mean, good. But but I’m sure I’m sure like like all developer tools are seeing the same thing, right? Well, at different rates. I think you guys are clearly one of the the leaders there. You know, I was going to bring out this one of these these things. I have this AEO tracker where you know if you if you type in Supabase and there’s a there’s a few categories where you’re the leader, but basically it has led to every single frontier model.

[2040s - 2160s] Recommending you as your primary choice for an integrated backend. What does integrated backend mean? It is your original offerings, like your your off your functions, your you know, and your database and all the other stuff APIs. And I think it is interesting. Like you had to be in the market for three to four years, exactly your time zone before LLMs took off, and then present yourself as the leading competitor to the leading thing at the time. Yeah. And then you can take over. Yeah, yeah, yeah. We’re very lucky with our timing. I mean, we couldn’t have timed it better. Like it’s complete accident. Well, I mean, I think like on first principles basis. So we have interviewed other founders who maybe started post LLMs. Resend was kind of there. We’ve also talked to them. Like, why does my LLM keep recommending Resend? And it’s because they have a lot of good AEO practices. Sure. Yeah. And of course, we invest very heavily in that. But you know, when we’ve been at that point since the start, and that was an accident, right? So now we just need to maintain that lead and community as well, right? Like our one of our growth strategies early was just was spending so much time with the community, and it resulted in they were writing blog posts, they were making YouTube videos, they were putting out podcasts, all about how to use Supabase, in what situations, like here’s how I built this thing. I’m sure that all just got slurped up by the the model. And open source helps as well, of course. Yeah, yeah, yeah. Being being open source, you actually had a fun announcement on the community side because you’re raising so much and you’re trying to involve your community in some in in more deeply. Yeah. So so last year at Supabase Select, we announced that we were going to do a crowdfunding round. It’s something we’ve always wanted to do, and we should have done it much earlier on, but we just you know had so many other things going on. And basically, then we spent the last year fighting with the lawyers who are saying, you know, for the number of people we want to be involved, there is no mechanism to do it without people being accredited investors. Until we asked them the question.

[2160s - 2280s] Well, what if they don’t invest? What if we just give them the stock? And they were like, “Yeah, we’ll look into it.” And then they came back and they were like, “Actually, there is a mechanism where, if you really just want to give the stock away, you can.” And so now we earmarked like a million dollars in Supabase stock that we’re basically going to give to a bunch of the community members. The first community member we’re we’re going to stand up on stage and sort of announce is is this guy. His name’s Gary Austin in the Supabase Discord, and this guy is like a legend of the Supabase community. He we looked into his stats, and Gary has answered twenty thousand in the last six years. Twenty thousand questions in the Supabase Discord, and the crazy thing is, thirteen thousand of them he answered within the first hour of them being asked. And he’s not a grockbot. Like he’s a real human. Yeah. Have you met him? What? Yeah, yeah. What is his deal? He’s real. We we met him. He he was basically like retired. Yeah. And just interested in Supabase. Gary Austin. Gary Abbott. Yeah, Gary Abbott is his real name. Okay, this guy. Yeah. Yeah. Okay. And and he loved Supabase because he basically built his own similar app because he loves red wine. And then was just getting a kick out of you know he’s got Supabase logo on his Christmas tree. And he’s also by the way, this is my favorite Supabase memes. They’re just like you reminding me that like I’m about to run out of my Supabase. That’s the announcement. Is we’re basically like anyone who’s a legend in the Supabase ecosystem, we can yeah. Is Discord still a strong? I mean, I got mixed feelings about Discord. It is it is the best chat. You know, Slack sucks, but also it is not public, right? So all the work in there is not scalable. Yeah. Have you found anything to solve that? There was some tools that we looked at in the early days. We we decided not to do it because you still needed to police.

[2280s - 2400s] Like what things you wanted to be public and and what things you didn’t, but the original debate that I remember we debated a lot was okay. We want to host the community. Do we do a Discord? Do we do a Slack community? Do we do a Reddit? And we tried a few different options, but we landed on this thing of like Discord users are going to use Discord, Reddit users are going to use Reddit, and we basically had to do all of the be where they are. Be where they are. Yeah, that’s the answer. It was a lot of work. Yeah, and it worked out. Right. I mean, that was the right answer. But then there’s a lot of like great tools that started popping up, right? Um, or I don’t think anyone has has stood the test of time. Let’s call it. But yeah, there there are there are tools. There are Discord mirror to public Q and A site. That is a thing that people do. I don’t know if it’s been successful for anyone. Yeah, and and like common room. Actually, the only thing that we did was for ourselves. So basically, anyone who had asked a legitimate question on any one of these, we then would basically scrape the question and the response into our own website. No, actually, we scraped it kind of into GitHub discussions and mirrored that onto our website. And so the content that was getting used GitHub as a CMS. Yeah, we use it as a CMS exactly. Yeah, it was a great strategy because everyone, ultimately, everyone was asking the same questions over and over again. So we’re just like, okay, well, we’ll surface it each time. Yeah, it can be confusing because there’s GitHub. There’s super based the open source, and then there’s super super based the cloud platform, and and most people are probably going to come into support for super based the cloud platform. Yeah, so yeah, it is. Yeah. Do you have any idea of your? This is very hard to tell your open source market capture. So this is a thing that like if you’re in the developer tools circles, you you know, you do. We like quite deliberately do not don’t know. So yeah, we don’t put any tracking in our open source offering. You can use it, and we’ve had enterprise.

[2400s - 2520s] Large pharmaceutical companies, for example, come to us and say, “Hey, we’re running a hundred instances of your open source project. Can you offer us a product?” So we’ve got this product called Control Tower, which allows enterprises to have monitor a fleet of databases. You won’t find it on on our website, but oh, come on, yeah, why not? Because it launches because oh tomorrow, tomorrow. Oh, I don’t know if we’re announcing it tomorrow, but yeah, basically, it’s Control Tower. All it does is is this fleet view. We’ve got this very popular product, Supabase for platforms. So that’s where all these AI companies are building on top of. We launch millions of databases for them, and so all we needed to do was repackage this for enterprises, and enterprises as well want to do the same thing, which is they want to spin up many internal superbase for all of their users. They want to see and administer them, and so Control Tower is essentially a repackaging of what we’ve already been developing for these platform providers, except specifically for for individual enterprises. Yeah, I do want to cover because I think a lot of people think of you as bottom sub GTM. You know what the work you’ve been doing on the enterprise side. So first of all, shout out to Ambu. Yeah, I think this is your most successful recent launch, which is Supabase for platforms. This one launched in yeah, yeah, yeah. I mean, December 2025. So yeah, but I saw some stats or like yeah, you guys call this successful. I don’t know. Yeah, what is the enterprise side, right? Like, what what are what is that story apart from like give me a dashboard? Well, first of all, we should talk about sales strategies. Okay, so Supabase is a very famously PLG company. Like we give a shit about. We have 60% of every YC batch use Supabase. We focus almost all of our attention on this, like becoming an index company. Basically, our role model here is Stripe. We want to follow in their footsteps. They’re one of the only developer tools that we’ve ever seen that has withstood more than a decade of moving up market.

[2520s - 2640s] And still keeping that developer love, so that’s the first thing. So to do that, all we started doing when we did sales was layer on what we call product lead sales. So we look instead for like product triggers. It could be like a logo, someone who we think is really important, but more importantly, they could be scaling up. They could be hitting some limits, having some errors, paying a certain amount. We’ve got a bunch of these triggers, and then AI came along, and we’re like, oh, we can do some interesting stuff from this. So let’s say we have a thousand product triggers every single week. We send off a thousand emails to people who are having problems, and say five hundred of them respond. We take the cohort who don’t respond, and we use them as a control group. Okay. And we measure how much they grow. Turns out they grow twenty five percent month over month. Then we take all those who do respond, and we say to our sales team, the only thing you need to do is get on a call with these people and help them. And because we’ve got all their traffic patterns, we can give them a script. We know what their problem is. AI has been great on this, and we give them a script just to help out. And it turns out just getting on a call and helping people out, their account then grows one hundred and twenty five percent. So that one hundred percent uplift, the incremental uplift, is what we compensate our sales people. Traditionally, you’d say get on a call with these people and just sell them shit, and then you get the full quota. But because we know our database grows, our platform grows at twenty five percent month over month on this cohort of users, then we know that our sales force are adding this one hundred percent incremental uplift. So that’s how we do our sales function. It’s always focused on these logos or very specific product needs. So yeah, the likes of the enterprise is usually coming in because they’re wanting to launch lots and lots of databases, or almost never it’ll be a transfer of their production database. So migrating databases from say MySQL to Postgres or.

[2640s - 2760s] From say one scalable database to another scalable database, almost never happens, and that was the core thesis of Supabase at the start. We knew that every single Postgres company we had looked at, or database company we had looked at in the past, that had tried to do migrations had failed. Over time, you just can’t convince people to migrate, even if you build a bigger, better, more scalable Postgres. What you have to do is land with them on day one, and then make sure that they stick around to day one thousand, day ten thousand. So all of our focus is winning these enterprise logos on on day one. Greenfield. Greenfield. Yeah, they’re still not migrating. I guarantee they’ll almost never migrate. There’s a cohort that will need MultiGress. We talked to some logos who are looking at using it open source. They’re very interested on making sure that they can basically help us direct because they’re running into problems of Postgres at scale. But for the next say five years, almost all of our focus on the enterprise side is making sure that we can handle greenfield use cases, which now in the enterprise it turns out to be a very prolific use case because they want all of their product people to be developing, innovating as much as they can. So again, it’s kind of perfect timing for us because that’s what we’ve been focused on for so long. This control tower is like one of our biggest things. MultiGress, of course, gives us the the opportunity to win these large workloads if and when they want to ever migrate. But it won’t ever be one of our core focuses, or at least not for the next say five years. We’re going to have to focus really heavily on just landing inside these enterprises and then expanding up. The other thing that’s changed is we obviously put in the past all of our focus into developers. So it was like selling to the developers, enable them as a champion, they help you sell internally. Interestingly, now we have like CPOs who are like, wow, I didn’t code for the last ten years, but now because of Lovable and Supabase, I’m building all these.

[2760s - 2880s] Things internally that we now have like champions at the at the sea level, and without needing to put like a huge motion around that. Oh, that’s great. Yeah. Mentioning Lovable, mentioning Bolt, Lovable is going to have their own database stuff, you know, and and like everyone is going to basically try to intrude on on each other’s turf, which is normal in in the in the grand scheme of things, which is more sticky. Which is more sticky? More more sticky. Like is the CPO more likely to be married to Lovable or married to Supabase? You know, like is is that a question that comes out? It’s a great question. I think ultimately running databases is very hard. Fair enough. Well, as we just discussed, it’s harder to migrate your database than it is your frontend tool. Yeah. Yeah. Not that I don’t think Lovable is sticky. I think it’s amazing, and actually, they were the first people to do a really good job of making sure their agent didn’t do stupid shit with the database because we had very early on the agents were like trying to shove image data into Postgres. You know, they were turning off RLS in order to get their projects to work. And paperclip-maxxing basically is that Lovable wrote really good skills to stop their agents doing stupid stuff. They would they were the first. That’s the secret sauce. Yeah, yeah. Yeah. To solve all these and and and now like the models themselves don’t do that stupid stuff anymore. Yeah. So it’s it’s the situation has improved a lot. It’s gone from like Will Smith eating spaghetti circa you know 2022 to Will Smith eating spaghetti in 2026. Yeah, yeah, yeah. And that’s a that’s a famous meme. Talking about, I’ll leave the migration point alone. After I mentioned this, you know, one of the things that I got like a big aha moment was when I met Karen from Co2, one of your board members, and she said like her thesis is whole like you know you are not just replacing Firebase, you’re also like you know coming up as like new new RDS right for for Amazon. If there was a you know stage four of four.

[2880s - 3000s] Era post AI of superbase that is like the other you know the one trillionx in your in your growth rip out Oracle I don’t know like yeah what is is well that’s the that’s the that’s the one that the famous migrations are after I heard some crazy stat like that it might be different now because they’re trying to Oracle are trying to move everything to the cloud but I think it was like one year ago someone said that only five percent of Oracle workloads by revenue ran in the cloud and so like almost everyone was saying oh let’s rip out Oracle let’s do migrations people that’s what I mean though yeah like when I look through the history of database providers who have tried to run this strategy it sounds amazing and it’s something that we will of course try to do ourselves why would we not try to do this but it is incredibly difficult and I think you will just want to focus first and all on landing inside the enterprise yeah that makes sense it’s one of those things where like you know when when I see I talk to coding agent people all day long the great promise is that you can finally migrate off of all this legacy software that you have yeah right and like hopefully that that means that you cut over everything that’s true because one of the things that actually makes Oracle so sticky is like you end up writing these million line stored procedures like you stuff everything into your database and so actually probably rewriting that is these days a lot easier right right so like hopefully coding agents are the boom maybe they’re not there yet maybe you guys have to become more on prem most of the problem around migrations is actually not not rewriting it and you can do migrations for example on the data analytics side quite easily from one from one warehouse to another the problem is that usually your OLTP database is powering your most revenue generating application so a minute of downtime means that you end up with basically dollars lost and so then what you end up doing is having to run these two things in parallel and then the risk of this is

[3000s - 3120s] That you get this split brain where you’ve got some data running on one side, some on another, and if you try to reconcile split brain, anyone who try to do it is a very hard problem. So the risks are just so much higher when it comes to OLTP that a lot of the time people just start doing splitting the workloads off, and they’ll start new workloads. They’ll do a lot of operations here, and hopefully they’ll migrate things over. Yeah. Usually, then you’ve got two problems though. Well, speaking of OLTP, I mean, this is just like database indulgence. We also had two of the co-founders, the data bricks here, Matei and Reynold, where they are making a claim that they have solved HTAP. Okay. Yeah. Which is the sort of the white whale of database people, right? If you know, like, well, traditionally you need an OLTP, you need OLAP databases. Yeah. Um, never the two shall meet, except that sometimes you you would like to never have to replicate anything. Yeah. How you are you paying attention at all to that stuff? Like, is is there is there a story there for Supabase on someday? Yes, we are particularly interested in Duck Lake. I think Duck Lake is a very and Duck DB is a very interesting thing. Mother duck, but a but a data lake. Like what what is what is Duck Lake? Ah, Duck Lake. Okay, so Duck DB. Yeah. Which was recently it’s Duck DB, which is basically like a SQLite for analytics columnar storage. Yes, exactly, exactly. Can read directly from object storage. That’s typically how it’s touted, and it can actually read from your Postgres database as well. So, open source, great technology, and actually there’s also DuckDB Labs, which was recently acquired by AWS. Yeah. So there are foundations that are developing. So they’re building a committee around the open source. I actually think of DuckDB a little bit like the Postgres of the analytics ecosystem, in that they’re trying to make it so that it’s owned by no one. It does a lot of things. It’s very versatile. It’s like a professor in Netherlands. Yeah, exactly. They live they live and work out of the Netherlands, which is.

[3120s - 3240s] It’s pretty cool. So our interest, mostly on the warehouse side, is not trying to make Postgres an analytical database, but mostly then focusing on using the right technology for the right job. I don’t know if HTAP. Many people have tried to slay the HTAP dragon. Object storage could be the solution to that. But generally, we think once you get to a certain size on the OLTP side, you need to have sharding. There’s a limit to the amount of NVMe disk space that you can have. So if you need to split transaction across two servers, you’re basically then going to be fetching it from object storage. Eventually, that will slow down your database. So we think that sharding is by far the best way to do scale up into the petabytes. And then you should treat your analytics differently. Now that doesn’t mean that you shouldn’t store your data directly on object storage, for example, and then read from it from a different route. But trying to smash these two together doesn’t necessarily make that much sense, in my opinion. Yeah, I’m happy to leave it there because we do have more to work on. I do think you know they have some innovations where they’re they’re basically using their spare compute on their database machines to power all this replication. Is is my read of what they’re doing? And actually, to be honest, I haven’t looked so much into how they’re doing HTAP. So I could be misquoting. Yeah, exactly. It’s it’s like you’re you’re in your lane. You know, it’s not exactly like your customers are like banging the table asking you for this. Yeah, it is just like if you want to become the preeminent database company, someday you have to have an answer. Yeah. Yeah. Exactly. Yeah. Which like yeah, it’s it’s interesting. The other mention I will check in on is durable workflows and and you know that world. Ah yeah. Which as you know, Temporal. Yeah yeah. I’ve been I’ve been banging the drum for a while. You have made like every year you made you do a little thing. Yeah yeah, we’re incrementing. Yeah. But like, don’t you like? How come it’s not like more P zero for?

[3240s - 3360s] You because like you know Temporal is doing super well, right? Okay, so what was missing for us to do durable workflows compute? Right, so you’re you’re doing this now. Yeah, super interesting space to be in. I think like yeah now we have had people in the community try to build workflow engines on top of Supabase functions and it just didn’t work because the two second timeout. Yeah. Now we’ve got the primitive that would unlock the ability to do long running durable workflows. I think my original pitch for Supabase is like you want the sort of the all in one the the sort of agentic cloud that like is the backend integrated backend that that people can can use right like you’ve got Sign in with ChatGPT now which is a great part like you you just kind of have to sort of give the AI everything it wants and then it will be your best friend. Yeah, yeah, pretty much, pretty much, and be prolific. I mean, our P1 strategy is to partner with as many of these frontier labs and models as we can, so we’ve got to be prolific there, and then we basically we see our attach rates just going up as well. Yeah, I mean, obviously, there’s the US labs in you’re you’re here in the US. Do the other labs have significant partnerships? What what are they like Mistral, Cohere, the Chinese labs? I don’t know if not so much. What’s in here? Well, they might they might do. Okay, you primarily care about the US. Yeah, yeah, yeah. Okay, okay, that’s very unfair. Yeah, yeah, mainly just because like that’s who’s delivering the most traffic at the moment, right? That could change. Yeah, but what does partnership look like? Like basically, it’s one thing to be on the their app store. It’s the other thing to be their default thing when they when you launch an artifact. Yeah, so that one’s super interesting for us to be able to hopefully be one of those providers. One of the reasons why we couldn’t in the past was because we just couldn’t handle their scale. I mean, take ChatGPT for example. What have they got now? A billion monthly. One point two. One point two billion monthly active users. One of their users launching a database every single month. Now we’ve got to launch one point two billion.

[3360s - 3480s] Postgres servers, it’s just as I said, we’ve got to get to the billions of databases per month. We just haven’t been able to do it until today, where we acquire a company that means we’ve got the technology which can drive it up. Scale up, scale up. Okay. Other than that, what are other, I guess, P zero objectives for the company? Like you know, over the over the next year, how are you sort of guiding the direction? Our P zeros are basically win the strategic labs, win the models, and continue our PLG push, where we focus on the enterprises is winning these new workloads. And it’s more that like the ceiling of PLG. When we started the company, we were like, we can get to 100 million on PLG. We can probably get to 200 million, but then we’re going to need to do something different in terms of motion. But because of AI, like that ceiling just lifted, and we don’t know where it got lifted to. Like, is it a billion? Is it two billion? Is it you know you could just we could just keep going, but we still want to do the other stuff as well. So we basically like last year we were like, well, we have to do both, the both the small stuff and the big stuff, and you know maybe we’re a bit greedy. No, I think it’s it’s what people want, right? The same sort of mental model that and you know they’ll they’ll pay you to handle the fine grain details of moving up in terms of orders of magnitude. Yeah, and I don’t know how many orders of magnitude that is, but quite a lot. Quite a lot. It’s just crazy because if you would have asked us 18 months ago, we were growing fast. If you would have said, “What can you do to 10x your top of funnel?” I would have said, “There’s nothing.” Like it’s it’s crazy, right? And then just this whole market just exploded. So let’s see what happens. Yeah, I remember at our company offsite at the start of the year, we we put this crazy ambitious revenue number out, and someone came up to me and said, “Ah, you shouldn’t have said that number. Like the team are going to be we’re going to miss it. We’re going to miss it. The team are going to be so disappointed.” And it took us like four months to hit the number. It’s just like a ridiculous.

[3480s - 3600s] Ridiculous growth curve from the start of this year. Amazing. What are the open questions that you have? Like, you know, if you had a crystal ball, that it would change the way that you bet on things. How development will be done, and what people will develop. These are the two things that I think a lot about. Okay. You know, what are possible answers? It’s just more, more agents. Like, yeah. So, like this year, we’re focusing a lot. Like, and I’ll talk about it in my keynote. Basically, that we’re moving from like we started as a dashboard company. That was the best DX. Then, like, you know, a lot of people are like, oh, headless mode. Headless was what we kind of started. Headless 360, Salesforce, all these sort of things. I mean, we had that at the start. Like, you could use Supabase directly, API driven. That’s one of the reasons why we succeeded. This year, our big focus is moving from from to code first, get native. So basically, when you launch a Supabase instance inside your local machine, you get the Supabase folder, and it represents your database. It has all your functions every day. Does this exist today? This exists today. If you use the CLI. So it’s a virtual file system. Like it’s a representation of it’s like infrastructure as code. Okay. Yeah. And in fact, what we’re announcing tomorrow is like we’ve done our kind of final change for declarative schemers. This was a really challenging one, actually, covering all of Postgres. And so now you can have a full file representation of Postgres, the shape of your database declaratively in your folder. That’s really important for agents because generally how you operate with Postgres is you have a migration file every time you make a change, you add a file to this migrations folder, and it’s like a historical log. Okay. So that’s great. It’s industry standard. But imagine putting an agent across a thousand files and telling, asking it, oh, what is the shape of this table? It has to guess through a thousand files. So it has to recompile. It has to recompile. It waits. Yeah. Or you have to launch the database.

[3600s - 3720s] Locally run the migrations up, and then you introspect the database. But that’s too slow. So basically, what we want to do is turn the schemas folder inside our our superbase folder into a completely declarative state of your database. And so we’ve captured everything from tables, policies, database comments, all inside these files. So we’re releasing a new library, PG Delta. You can use it with any Postgres database, but we’ve got mechanisms for for superbase. And so this is an important step for agents. We know the agents are going to operate mostly on code. They don’t want to reach out to anything. They’ve got to iterate very fast on the file system. So that’s fine. And today people are using CLIs. They’re happy with these harnesses. What I suspect we’re moving more towards is like at the moment I’m trying to do some development just on my mobile phone, for example, and I’m quite comfortably able to do it. Of course, I know what’s going on behind the scenes, so I’m telling it things that I know it has to do from an infrastructure point of view. But we’re getting to a state where I can imagine you don’t need to be an engineer. You you have an idea. You say to your phone, your dot or whatever personal agent you have, I want to build X, and one second later you kind of have this application live. You can iterate on it yourself. So these are the things that I’m thinking. Okay, what are the use cases that people are going to want if this is the case? Is it personalized? What do we care about? Are these things going to scale up? What are the mechanisms? How are we going to develop? And what tooling do we need to provide to make sure that we are the default provider in this new world? Any questions that you’re you’re interested in is for Crystal Ball into the future? As someone who’s been a software engineer now for like a few decades, you have strong opinions on like how the software should be built, right? Like in terms of like continuous integration or like continuous delivery or whatever.

[3720s - 3840s] And I find myself like pushing my opinions on the on the agents of like, oh, you want to do it in this way, and but now more and more like you don’t need to. But my worry there is, are they all just gonna like converge on one way of building software, or yeah, mode collapse, you know, which is great. They’re all gonna use super bases, fantastic. But but like the the thing that’s great about like the software development injury is like industry is like these are like famous flame wars, right? Of like, what’s the correct approach? Like, are we gonna lose that? Or yeah, so you want diversity in ideas, yeah, so that the best idea can win, and but then the models are just gonna make you so lazy that nobody even bothers to look at the details. Yeah, and and they just all converge on one way of building software, and then that’s you know, is it gonna be like a local maximum in terms of? Yeah, I I don’t know. I I do think yeah. So first of all, I think that’s a valid fear. I do think it’s out of your control. Yeah, and and yes, the low taste, let’s call it casual app builders, will will converge on whatever the the mean is, the model is, which is you guys. But then the the discerning high skill people will always really care about the details as as they should. Yeah, right. Which which will which will then filter down eventually. Yeah, is my idea. But these high skill people are gonna continue to be trained by. I don’t know. Yeah, yeah. I mean, I think I think people are passionate enough. It’s one of those things where, like, you know, I do think like you know the average college is probably screwed, right? Like, you probably don’t need to go to university anymore because you can probably self teach and just like you know get get your own job. It’s always been like this top tier of people that that are moving a lot of the the needle, and you need to, and and they will always find a way to have their own self interests be satisfied, curiosity in terms of like what what is possibly better. You know, the type of people that take a year off and go to the Recurse Center and just work on cool programming problems, even though they could be making.

[3840s - 3960s] Money in in industry and like yeah yeah. What do you disagree on between the two of you? It’s rare to have the two of you had. Ah yeah, that’s a great on on the pod. So you know, I want to capture this. I think one of the reasons we’ve been so effective, like working together, is because there are definitely situations when we’ll disagree. But as soon as the other person like pushes a little bit, yeah, the other person’s like, yeah, maybe you’re right. Let’s let’s try it. Yeah, so we never end up in like big bustups, and it turns out like most of that stuff actually doesn’t matter. Yeah, doesn’t matter anyway. Like as long as the general direction is is correct, then then it’s gone okay. But yeah, I can’t think of. But you guys are really struggling here. Oh my god. Yeah, which is why like because it’s it’s never an important enough thing. Like we’ve never had a bustup because it’s never been important enough to actually fight hard enough on it. Like and also we’re fucking busy. So like usually like it’s handling. Yeah, we’re trying to handle different parts of the business. Maybe it’s just like things are growing, and obviously you got your domain, and and you just need to work together. Yeah, yeah, yeah. Yeah, it’s interesting, you know. So Laura here, all three of us were in entrepreneur first in Singapore. You were all different working on different companies, and then you guys stayed back after the cohort. You were housemates after the cohort. Yeah, yeah. So we were all we lived in a house with seven people, and we were all doing different startups. Yeah, and so M was doing his startup. I was doing another one. This is before Supabase, and so like I think somehow your energies, you know, you you found that you were suitable working together and and working on this. Yeah, because like traditionally, especially in in an accelerator model, you’re pushed as a technical person to work with some domain domain expert, right? Um, but in the house we lived in, it was basically seven people who were all builders.

[3960s - 4080s] All technical people, and we found that pairing to just be like so much more effective, especially on when you’re building dev tools, because you are the subject matter expert as a developer. Is that we could could just get so much more done, and so then we ended up hiring most of the other people who lived in the the flat as well as our employees, Rory. Was first employee? Um, not the first, but the first to on go to market. Like now he runs all of go to the postgress guy was first. No, Angelico. Angelico, yeah, we had an intern, an intern from my previous startup. We just dragged him along. Yeah, and and then the other like first like full time hire was this guy Steve Chavez, who um, yeah, who was the Postgress maintainer. And the funny thing is, we were in the YC batch, and the advice they give you in YC is like, okay, we’re gonna give you a bunch of money. Don’t hire anyone. If this the big temptation is to hire a big team, and we went to our partner and we said, oh, but we’ve got this guy Steve. He’s the lead maintainer of Postgress, and he was like, hire him immediately. You know that he was like, forget the advice, go and get him of his reputation, or because it made sense for Supabase. Well, yeah, both. It just made sense that you know this was a technology we were very reliant on, and we’re going to lean in. And it was like, and the the funny thing is, we hired Steve, and we said, don’t worry about Supabase, just keep building Postgress and just making it awesome. Um, and then obviously if we have support requests or whatever, we can we can ask him. But um, and the model just worked really well. And then we ended up when Steve wanted to grow the Postgress team, just hiring more people dedicated to work on that project. Well, you guys are doing so much for community and open source. One thing I do have in my mind is like, what is the future of large commercial open source? Um, one obviously there’s a lot of slop, and and I’m sure you guys are dealing with that. But two, also, your dependencies are now becoming optional. Like you can just vibe code whatever you want. Anything.

[4080s - 4200s] Yeah, yeah, yeah. So, whatever is in your heads about the future of open source, I’d just love to hear it. I think the rewrite in Rust is a valid mechanism. I mean, someone came to me on our team and they’re like, “Oh, yeah, yeah, I’m rewriting everything in Rust that we’re doing.” Like, and I was like, “To what level are you going to rewrite the database? Are you going to rewrite Postgres? Postgres is not rewritten and is not in Rust, but I doubt down to that level you care. So, there’s like layers upon which you want to get to where things will be rewritten, and then you don’t want to be spending your actual innovation tokens or your actual tokens rewriting everything. So, there’s going to be like a collapse of almost every tool probably into, let’s say, is Rust if that ends up being the the ultimate way of writing things because it’s faster and more correct, and that will happen probably for most open source tools. But then after you’ve done this iteration and everything’s running on this highly effective language, then you’re not going to be rewriting it all of the things every single time. There’ll be a few winners. A really classic one could be, you say, Postgres. It’s written in Haskell, which is a very unusual language, and it’s very hard to maintain. Could it be written in Rust now? Yeah, probably it could. And the mechanism, the the function, is still valuable. And probably there’ll be, if that happens, there’ll be one Rust fork of Postgres, and that will be the winner for that particular category. But you haven’t done it yet, and your and a lot of your stuff is Elixir as well. Yeah, so that’s the other thing. Then you have to think on the infrastructure side. Elixir is like a really interesting language because of the Beam. Yeah. So, so then you start thinking when you’re operating things, what is the right mechanism for operating? So, but now you can change paradigms pretty much easily as long as you fit all your tests and you know. Yeah, yeah. Well, that’s a good one. I haven’t thought a lot about would we switch Elixir to Rust.

[4200s - 4320s] It’s just an option now. Malte from Vercel is, you know, one of his tweets that sticks in my mind. He’s got lots of interesting thoughts. He set aside some amount of money and rewrite all of our dependencies at the C level or C plus plus level into Rust because we just know it is better, is safer, more correct, whatever. And it is it is a one time upgrade of open source. Yeah, all the drivers, whatever whatever you you use. So I thought that’s like a pretty interesting. I like that as an idea. Yeah, I don’t think it’ll happen because people love to do it themselves. Yeah, but but as an idea, I I would like we as a company would one hundred percent get behind that. Awesome. And then I think closing question, which I I should have stuck in somewhere earlier: AI coding within Supabase, right? Obviously, you guys are big beneficiaries of coding agents outside. What is the policy internally? How much are you spending? Is there is there concern about spends anything of that sort? Supabase has always felt like a bunch of different startups like glued together. So we have like the auth product, and we’ve always been very insistent that they should make their own decisions, like on what tools they use, like how they behave as a team, like the reporting structure, and the AI policy was kind of no different. Is like a lot of people asking, “What is the AI coding policy?” And we were like, “Well, just it’s up to you as as your team.” I think we have started to consolidate a few bits, especially around cost. But as much as we can, we’d like to keep that model of like let the teams decide how they want to run things. That’s it. Very decentralized. I would say I am trying to figure out a number for company leaders to take home with them as like what is the market standard. And so what what are data points you can hang your hat on here? People say you know the average person is spending like twenty dollars a month, and then average employee is maybe two hundred dollars a month. OpenAI, you know, the sort of fiftieth percentile is spending maybe three to five thousand a month, and the

[4320s - 4440s] Top percentile is in the maybe hundreds of thousands, right? And so that is the rough idea. I think a good metric is basically what is your ratio of tokens spent to human spent, and it’s like for a lot of people it’s maybe zero point one, a tokens to to one human salary, and you know you can probably go up to one pretty safely. And if you’re over one point five, you’re probably in trouble, something like that. So our I just I say I luckily as a remote company basically everything that’s ever happened is documented. So I can ask our AI how much we’re spending. So currently we spend about three hundred k per month. Yeah, for six hundred people. No, like four hundred and fifty people. Four hundred fifty people. Yeah, okay. It gives people an idea. But but what you’ve said about like scaling the cost in terms of related to the number of employees makes sense. Also for us because we are hiring very quickly, so if we end up getting a lot of leverage out of just like you should be right, yeah, then you need a whole bunch of serverless employees that can spin up and down as you need, right? Yeah, exactly. Which is like yeah, like you know I I just had a CTO of you know another top startup say like he was worried about his company spend and I’m like well actually that’s your investment in everyone else and probably it’s very skewed, right? Like there’s there’s like two or three people that are super insane in your company and everyone else is like probably not using AI. Yeah, yeah. That’s exactly what we see as well. We’ve got a leaderboard and people we put the leaderboard up and usually people are a little bit ashamed, so they kind of like yeah, because you’re wasting money, probably. Yeah, and that’s also the wrong focus. Like the focus shouldn’t be on how much you’re spending, but like how much end to end, like in terms of systems thinking, you should be thinking like in terms of how many end to end processes are you actually solving that where you no longer need a human in the loop or collapsing down long running human problems that suddenly become very short problems. So that’s where we’re spending most of our investment on like how we’re using AI. Luckily, you know, as you saw, like every single thing that’s ever happened in Supabase is documented.

[4440s - 4560s] Because we’re an async company, so building a company harness like an agenda harness around Supabase is basically just formalizing. You can point AI at it and say, “What are our principles?” and it’ll document down all our decision-making principles for the whole history of Supabase. So that’s where we’re spending a lot of our time. Before we move on from people, we do have, I think, now like fifty open roles, and we are fully globally remote. So we don’t care where you are if you’re very good. Same salary everywhere, right? Yeah, same salary regardless where you live. If you’re very good at what you do, please take a look at our job board. Yeah, can you can you like one profile? Just pick one, whatever is top of mind as as your highlight for what you’re looking for and why. SREs, okay, yeah, why? Because we’re just growing at a ridiculous rate. We need all the SREs we can get. What is a quality that is like you know you probably get a lot of SRE applications and you don’t look at them like what what stands out? The thing that we really care about is that you you actually want to work remotely. So it’s this is a strange one, but yeah, it’s true. We get a lot of quality people, but to fit in at Supabase, you kind of need to thrive in a remote first environment, like a fully async environment. It’s actually not for everyone. We learned that pretty early on. People would come in and they’d be like, “Oh, this is like I need to see humans.” My typical model of an SRE is like this gray beard that’s like sitting in a dungeon somewhere and doesn’t want to talk to humans anyway. That’s the perfect person. All of those people, please apply. Hopefully, they listen to the podcast. Yeah, yeah, no, I mean, yeah, we we we probably do have a lot of graybeards in SREs. I think one of I have been on the record as saying AI SRE is one of the hardest categories for for agent startups. I think I might be wrong soon, but so far it’s been correct. Like AI has not cracked SRE for for whatever reason. No, no, no, no, not yet. I agree. Yeah, like building software is you know debatable. Solve problem.

[4560s - 4598s] Maintaining, like keeping things running, yeah, is a whole different beast. Well, okay, well, thank you for keeping things running for everyone else. You guys, congrats on your journey, man! Like, I’m so proud to be your friend. Thanks, and an investor, and just like, just see the progress. I cannot wait for the IPO, whenever that is. It looks like it’s going to take some more time, but it’ll be, it’ll be fine. I really want to see you guys, like you know, do the whole ring the ring the bell and you know, building the next great open source company, right? Excellent, definitely, man. Yeah, thanks for having us.