Paul Copplestone：为 AI 构建者和智能体提供数据库

Lightcone 主持人欢迎 Supabase 联合创始人兼首席执行官 Paul Copplestone，讨论在更多人和 AI 智能体构建软件的世界里数据库会如何发展。Copplestone 乐观地认为，使用 AI 可能让更多人创建和定制应用，同时承认未来工作存在不确定性。

Copplestone 表示注册用户约为 1300 万，而一年前估计约为 300 万，并说公司预计当年收入增长四倍。嘉宾还提到每周创建约 100 万个数据库、管理中的数据库接近 5000 万个。这些是对话中的公司数据和预测。

他将增长归因于工程师构建更多产品，以及没有工程背景的人也开始构建。主持人区分了知道如何实现软件与知道什么问题值得解决：领域专家现在可能不必先找到工程师，就能尝试自己的想法。

Copplestone 描述了 Supabase 的三个阶段：控制台优先、API 优先，如今则是代码优先。他说智能体通常偏好代码和命令行界面，而在模型生成的工作流程中成为默认选择使公司受益。

被问及开源的作用时，他表示很难知道如果不开源会怎样，但他认为开源很重要。Supabase 参与并支持 PostgreSQL 生态中的工具。他认为访问源代码可以帮助智能体调查失败，主持人也讨论了它对供应商安全审查的价值。

Copplestone 表示，在他描述的时期，新注册、激活和转化指标一起上升。他看到此前不会写软件的构建者增长强劲，同时指出传统开发者仍是用户群的重要组成部分。

一位主持人举例说，一名金融科技创始人过去依赖工程师，现在可以自行构建个人财务工具。Copplestone 表示，领域专家能够发现开发者可能永远不会遇到的细分问题。他还回忆，一位巴西出租车司机在手机上构建了当地出租车应用。

一位主持人描述自己构建个人“控制塔”：最初他以为只需通过聊天互动、用 Markdown 存储一切，后来却加入了界面和数据库。应用整合了邮件、财务、健康和其他生活部分。他重视的是可以为自己定制，而不必面向大众市场。

主持人讨论跨服务结合上下文，例如把日历与健康数据一起使用，同时指出这些例子是个人解释，而非医疗结论。Copplestone 说，他已开始把个人数据从单一智能体中提取出来，以便将其他智能体连接到同一底层记录。

他们将个人数据库描述为可以支持不同应用或智能体的权威数据存储。一位主持人说，他的系统也接受文件，并通过 Supabase 存储。在他们看来，吸引力在于可以更换界面或智能体，同时保留数据。

被问及未来每个人是否都可能拥有个人数据库时，Copplestone 表示，他预计许多能够使用 AI 的人都会成为构建者。他解释，Supabase 最初专注于从第一天服务 YC 初创公司；如今同样的目标扩展到了更大、更多样的用户群。

他用大量 AI 用户作假设比较，说明可能面临的规模。这是规划情景中的算术，而非每位用户都会创建数据库的证据。它引出了传统数据库产品过去不必假设的架构和成本问题。

Copplestone 说，小型原型不一定需要与最大工作负载相同的资源。他讨论了 Supabase 对 Turso 的收购，以及面向入门用户的拟议 Spark 层，同时强调需要支持不断增长的客户。他描述的目标是建立从原型到大型数据规模的路径。

嘉宾询问数据库公司如何同时服务个人构建者和企业客户。Copplestone 表示，公司正尝试用不同架构满足两端需求。即使有 AI 协助，在快速增长期间招聘并支持如此广泛的需求仍然困难。

一位主持人引用内部调查，称 Supabase 工程师中使用智能体编写大部分代码的比例上升。Copplestone 表示，公司让员工使用工具，而不是规定单一 AI 政策；工程师看到更好的结果后逐渐采用这些工具。

他说，团队用 AI 编写更多代码时尤其重视测试。主持人观察到持续集成和代码审查工具的需求增加。他们讨论的是评估结果所需的工程工作，而不是说生成代码天然正确。

回顾控制台阶段，Copplestone 说，即使开发者也觉得数据库难用，因此他想到在 PostgreSQL 之上构建类似电子表格的界面。后来一个集成伙伴需要通过 API 创建大量数据库；他说这个决定为后来的应用构建工具做好了准备。

随着更多工作离开控制台，Copplestone 说他要求团队让产品以代码为先、原生支持 Git。控制台中的能力也应能通过代码使用，公司还为沙箱环境重做了命令行工具。

嘉宾比较了 Parse 和 Firebase 等早期后端产品，并回顾移动设备和数据库偏好变化如何创造机会。Copplestone 表示，这些公司帮助证明大型云服务商之外也可以建立数据库业务。

他们讨论了早期赢得客户并随客户扩大的挑战。Copplestone 说，在数据库供应商之间迁移很困难，因此 Supabase 希望从企业第一天开始服务，并在其增长时留住客户。他也提醒，自己听到的 AWS 初创客户收入统计需要核实。

一位主持人认为，个人数据库用户可能不会像初创公司那样扩大规模，但可能多年持续使用。Copplestone 看到个人生活中存储的数据不断增长，将其描述为潜在的消费者和专业消费者市场，而不是对每位用户的已证实结果。

Copplestone 说，在助手休假期间使用个人智能体，让他对这一市场更感兴趣。他描述了亲自使用产品的方式：构建时与智能体交谈，而不是不断检查代码，以体验未来客户可能使用的工作流程。

一位主持人设想派智能体参加开发者大会，了解新功能并将其整合进项目。几人开玩笑说可以举办只面向智能体的会议，随后回到让工具更易被智能体使用的具体产品选择。

Copplestone 说，一条通用错误信息可能只告诉人类发生了错误，却没有为智能体提供恢复路径。团队改进了信息，使其建议解决方法或指向文档。目标是帮助智能体解决问题，而不是立刻放弃产品。

他说，Supabase 会用不同模型测试工作流程，维护内部评估套件，并研究 PostgreSQL 用例。更多工程工作正在用于测试人和智能体如何构建，而不只是增加功能。公司的测试是其自身衡量方式，并非独立认证。

一位主持人介绍 Gbrain，一套从早期研究工作流程发展而来的检索系统。问题在于从庞大的个人或公司资料库中选择相关上下文：智能体即使有很长的上下文窗口，也需要在正确时间获得正确材料。

他描述了在托管 PostgreSQL 上结合检索、向量搜索和图结构，由 Supabase 管理底层数据库。他说自己在实现前要求编程工具研究检索方法，随后讨论了智能体为重复查询改进索引的可能性。

主持人说，他从生产轨迹中提取评估数据集，测试检索质量、成本和延迟等类别。他描述了尝试变更、保留改进并记录失败的自动循环。这是他自己的实验流程和指标，并非通用开发建议。

嘉宾询问未来的构建者是否需要理解评估，还是智能体会处理更多过程。Copplestone 回忆自己通过与智能体交谈构建开发者网站，同时承认工程背景帮助他知道自己想要什么。

主持人将快速变化的模型能力与决定要构建什么、如何产生影响这一较慢的任务作对比。Copplestone 表示，他对创业能让此前缺乏技术资源的人参与感到兴奋，但未来仍不确定。

对话转向垂直软件初创公司和融资。主持人认为，拥有可观经常性收入的小团队未必总需要仅为获得认可而继续融资。他们举出的收入和利润率是情景示例，并非对典型初创公司结果的承诺。

被问及创始人如何适应一次又一次技术浪潮时，Copplestone 提到了持久的业务类别、亲自使用产品、合作伙伴关系以及为团队保留实验能力。他说许多实验会失败，但快速反馈可以找出少数有效的方法。几人以保持适应能力结束对话。