Cursor CTO：扩展数据库最佳方式是不要数据库

“扩展数据库的最佳方式就是不要数据库”——Cursor 联合创始人/CTO

1、AI的规模和传统互联网不一样。
以前说“规模大”就是网站访问量多。但AI的规模大，意味着每天要在自己的电脑上处理上亿次昂贵的智能计算，这可是个完全不同的挑战。

2、AI产品就像三脚凳。
好的AI产品需要三个部分一起工作：一个索引系统来找到正确的上下文，一个模型来进行推理，还有一个聪明的用户界面来让输出结果有用。光有模型是不够的。

3、“无限扩展”的数据库是个陷阱。
新的、复杂的数据库看起来很酷，但其实很危险。Cursor公司就吃过亏，发现先掌握那些简单、可靠的工具，比被复杂系统搞晕要好得多。

4、“雷鸣般的群体”对AI来说是个大威胁。
当一个智能服务重启时，最先上线的几个节点会立刻被用户请求淹没。它们会立刻过载并崩溃，形成一个“死亡螺旋”，让恢复变得非常缓慢和复杂。

5、危机中，有些工程师会冻结，有些则会大放异彩。
在大故障中，有些工程师会不知所措，但最有价值的那些会“活跃起来”。在高压下保持冷静和优雅，对一个高风险的基础设施团队来说，和技术水平一样重要。

6、清理比修复更难。
在事故中，最耗时间的不是写新代码，而是清理。对Cursor来说，简单地删除一个20TB的坏数据表，本身就成了一个巨大的工程项目。

7、最好的数据库是没有数据库。
扩展数据库的最好方法通常是避免使用数据库。通过将数据移动到不可变的存储（比如S3），你可以利用超优化的、全球规模的服务，大大简化自己的架构。

8、Postgres的更新其实是性能杀手。
数据库的一个重要知识点：Postgres的更新不是直接修改。它是一个删除后插入的过程，会产生“死行”和写入放大，可能会让一个更新频繁的系统崩溃。

9、AI让计算机科学的基础更重要，而不是更不重要。
AI不会让工程师失业，反而会让优秀的工程师更有价值。通过自动化那些繁琐的“怎么做”，AI提升了系统架构、问题分解和“品味”等核心技能的重要性。

10、创业的决定应该是显而易见的。
你应该辍学去创业吗？如果你需要问，答案可能就不是。对于真正的创业者来说，这个想法的吸引力是如此强烈，以至于感觉像是一个选择，更像是一种冲动。

11、真正的护城河是数据飞轮。
在AI中，最坚固的护城河不仅仅是拥有数据，而是拥有一个高吞吐量的数据飞轮。Cursor的核心引擎是一个实时流媒体基础设施，它捕捉用户互动来不断改进他们的模型，让产品随着每次按键变得更智能。

网友热评：
1、他说得一点没错……这就是我如此热爱 Cloudflare 的原因。队列与 Worker 结合，结合 R2 和 DO，构成了一个如此引人入胜且强大的生态系统。再加上边缘计算能力和低延迟服务器端渲染……我的意思是，真正的低延迟，低于 100 毫秒的客户端服务器生态系统，以及低于 10 毫秒的事务处理……他们能够长期保持独立，这令人着迷。

2、YouTube链接：https://www.youtube.com/watch?v= 4jDQi9P9UIw&t=522s

3、如何利用 s3 作为数据库呢？
我猜这和大数据团队的做法一样，只插入（追加），不删除/更新。只需要跟踪记录的最新版本。
另一个优点是，现在您的存储和计算已分离，因此您可以根据需要扩展后者。
类似大数据Apache Spark

4、Cursor肯定有一个数据库。
扩展数据库的最佳方式是不要围绕它构建产品。
每个“UX 设计师”都认为所有内容都应该放在可排序、可过滤、可搜索的表格中，并具有内联编辑、实时更新、无限滚动、旋转、列选择、导出等功能……

5、我认为，使用 Athena 这样的工具，如果你真正需要的只是“状态”，那么将数据直接存储到 S3 就足够了，然后对于查询需求，只需使用 Athena

附十年前文章：

板桥里人 https://www.jdon.com 2005/04/28

以数据库为核心的软件时代已经过去，数据库时代早已结束，当我看到J2EE征途中那么多人在对象和数据库之间彷徨痛苦ing的时候，我想我该出来喊一声了。

其实这句话在几年前肯定有人喊过，因为中间件时代的来临，实际意味着数据库时代终结，正所谓一山无二虎：如果你重视数据库，你的J2EE系统就无法完全OO，只有你忽视数据库，你的系统才有可能完全迈向OO，至于数据库性能调优等特定功能都可交由EJB容器或O/R Mapping工具实现。

很多年前，包括我自己在内的大部分企业程序员都是从数据库开始我们的职业生涯，最早的是dBase/FoxPro，后来有了 SQL系列数据库, Oracle将数据库时代推向了顶峰。

每当有一个新项目时，第一步就是首先设计出数据表结构(Table Schema)，然后开始使用SQL语句实现业务逻辑，这种开发模式一直重复，就是后来加入了DelPhI/VB，他们也只是承担图形显示实现，这种C/S结构带来最大问题是：非常难于维护，修改起来，迁一动百。

软件的生命在于运动，当它需要发展时，最棒的软件人员如果对他也束手无策，这是谁的悲哀？

现在更多人开始接受B/S结构，但是他们中很多人还没有真正明白为什么需要B/S结构，B/S代表的多层架构才是真正目的（因此，伪多层的B/S系统遍地皆是）。

多层架构实际是将以前系统中的显示功能、业务运算功能和数据库功能完全分开，杜绝彼此的耦合与影响，从而实现松耦合和良好的可维护性。

一. 从设计上说：由于实现层次完全分离，业务运算功能成为一种中间功能（中间层），它不依赖具体的表现层技术(Jsp/Html applet等)，也不依赖具体数据库技术（Oracle/SQL Server），业务运算功能运行在J2EE应用服务器中，当我们的业务运算功能不再依赖数据库时，是否意味着数据库已经不是重点？

二. 当然，多层结构带来了性能问题：客户端访问数据库中的数据时，通常需要经过多个层次，非常耗费性能， 如何尽量减少数据库访问是J2EE应用系统首要解决的问题，使用存储过程并没有解决这个问题，存储过程的执行还是属于后端，并没有缩短客户端请求所要经历的坎坷路途。

解决性能问题的根本解决之道是使用对象缓存，现在， 64位CPU提供的巨大内存空间为单台缓存计算提供了硬件基础，更重要的是，这种缓存计算是可伸缩的，通过集群的缓存机制（如JBossCache）， 通过增加应用服务器的数量，可以提高整个业务逻辑层的缓存计算能力，抛弃过去那种为内存斤斤计较的老思维吧。

三. 在系统分析之初是否首先需要数据表设计呢？回答是否定的， 以UML为代表面向对象的分析设计方法已经成为强大工具，随着面向模型驱动分析设计（MDA/MDD/DDD）的普及， 面向数据库分析方法正在逐步被抛弃，拥有深厚传统数据库分析习惯的程序员必须面对和接受这种挑战。

纵观整个J2EE系统开发过程，数据库已经从过去的中心位置降为一种纯技术实现，数据库只是状态持久化的一种手段（文件是另外一种实现手段）；什么是持久化？这是相对于内存缓存状态而言，持久化就是当内存断电情况下能永久保存状态数据，但是如果J2EE应用服务器是7X24小时集群运行；几乎永不当机，是否有持久化的必要呢？

很显然，数据库已经沦为与操作系统中文件系统同样的层面，以它为中心的时代真的结束了，IBM早期将DB2数据库开源已经强烈向我们昭示这点。

对于J2EE初学者来说，尽早抛弃过去的两种影响：过程语言编程习惯和以数据库为中心的设计习惯，从全新的面向对象角度(OOA、OOD和OOP、AOP)来设计开发你的J2EE系统，J2EE设计开发三件宝：Model、Patterns和Framework。

以上不只是理论，而是我每天正在做的，如果你也是或赞同请广为传播，唤醒更多彷徨痛苦的初学者。