数据管理为什么从文件走向了表格？
数据管理是从Excel这样的文件起步的。客户文件、订单文件、员工文件分开建立后，四个问题会不断累积：同一个人的信息在多个文件中重复，各文件的库存数字不一致却无从判断哪个正确，检索时必须扫描整个文件，两个人同时保存时其中一方的修改会丢失。
1970年，IBM的数学家埃德加·科德提出了解法：把数据存成有行有列的表，用连接（join）把表关联起来，并通过规范化让同一信息只存放在一个地方，从而消除重复。这套关系模型和SQL主导了之后50年，1977年的Oracle、1995年的MySQL以及PostgreSQL都建立在这个基础之上。
NoSQL和云数据库用什么换来了什么？
2000年代中期社交媒体兴起后，把一台服务器换成更好设备的垂直扩展撞上了天花板。把表拆分到多台服务器上会让连接查询变慢，于是NoSQL出现了：让出一部分准确性，换来速度和水平扩展能力。所以以准确性为生命线的银行至今仍用关系型数据库，而社交媒体用NoSQL。
到了2010年代，由云厂商代管安装、备份和容量的托管数据库成为常态。数据库从需要自己安装的东西，变成了像电一样插上就用的东西。
存储为什么从服务器中分离了出来？
文件存储走过了同样的路。早期Web服务把用户文件堆在服务器的上传文件夹里，服务器一挂文件也随之消失，服务器一多就搞不清哪个文件在哪里，仅文件传输就能把流量堵死。2006年，亚马逊S3把文件存储从服务器上剥离了出来：上传文件后由多台服务器复制保管，并返回一个访问URL，这就是对象存储。再加上CDN把文件预先复制到全球各地的边缘服务器，连传输速度问题也一并解决了。
Supabase把什么捆到了一起？
2020年问世的Supabase正是这两条脉络的汇合点。Firebase靠一次性提供认证、数据库和存储而走红，但它基于NoSQL，处理复杂的关系数据和精细查询时力不从心。Supabase把同样的便利搭在了真正的PostgreSQL之上：建好表，API就自动生成；文件访问权限也与数据库中的用户信息联动管理。从把服务一个个分别拼接的时代，变成了所需之物从一开始就连接好的时代。
非开发者了解这条谱系后会有什么不同？
下指令的水平会不一样。你可以说，图片放进数据库会变慢，所以上传到存储、数据库里只存URL；也能区分哪些数据准确性优先、哪些数据速度优先。SH Consulting在面向非开发者的Vibe Coding培训中，先讲这条谱系而不是工具用法，原因就在这里。