2009 年前后，我们整个开发团队共用一台 IBM 小型机。
不是因为穷。是因为那个年代，在本地跑一个 PostgreSQL 实例这件事，根本不在选项里。数据库是服务器上的东西，不是你桌面上的东西。开发环境里想连数据库，就得连那台小型机。
改个表结构？和 DBA 说。申请一个新的测试库？排队。那台机器上的事情，不归你管。
准确说，不只是数据库不归你管。那台小型机上的几乎一切都不归你管。
因为本地开发机根本跑不起来项目。一个 J2EE 应用，Maven 打包、部署到 Tomcat、跑起来——本地机器的内存和 CPU 撑不住这个流程。你的电脑就是一个码字机，一个稍微高级一点的 Eclipse 文本编辑器。代码写在本地，但编译、打包、运行，全在远程服务器上。
SVN 提交，远程 build，SSH 进去看日志，想 debug 就远程挂 JVM。整条开发链路都在那台机器上排队。
那时候我觉得这很正常。毕竟"开发机"本来就该是这样的，不是吗？
后来有了本地虚拟机。
VirtualBox、VMware Fusion，在自己的 Mac 上跑一个 Linux，Linux 里跑 PostgreSQL。终于可以自己建库、自己建表、想怎么折腾怎么折腾，不用排队，不用看 DBA 的脸色。
那种感觉现在很难描述——就是第一次觉得数据库是"我的"，不是"他们的"。
代价是启动虚拟机要等，资源占用高，切换版本麻烦，换台电脑一切从头。但比起排队，这些都是小事。
Docker 出现之后，事情变得更轻了。
docker run -e POSTGRES_PASSWORD=password -p 5432:5432 postgres:15
一行命令，三十秒，数据库就起来了。想换版本，换个 tag。想销毁重来，docker rm。本地同时跑三个不同版本的 PostgreSQL 测试兼容性——这种事在虚拟机时代想都不敢想，Docker 让它变成了日常操作。
Postgres.app 在 macOS 上更进一步，连命令行都省了，菜单栏点一下，版本随便切，数据库在本地安安静静地跑着。
这大概是工程师和数据库关系最亲密的一段时光。数据库就在你的电脑里，你可以打开文件系统看到它的数据目录，可以随时进去翻配置文件，可以在它挂掉的时候亲手把它重启。
你摸得到它。
然后，不知道从哪一年开始，风向变了。
个人项目越来越多，但时间越来越少。每次启动一个新项目，搭本地数据库环境那几步开始让人觉得烦——不是做不到，是没必要。
Neon 出现的时候，我试了一下，注册、创建数据库、拿到连接字符串，五分钟之内搞定，免费额度够用，serverless 架构按需计费，冷启动也还能接受。Cloudflare D1 更极端，SQLite 语法，跑在边缘节点上，连接字符串都不是传统意义上的数据库连接，就是一个 API。CockroachDB 是分布式的，在全球多个区域有副本，你根本不知道、也不需要知道你的数据实际上存在哪台机器的哪块磁盘上。
数据库又变成了别人的东西。
但这次不是因为资源稀缺，也不是因为没有权限——是因为你主动把它交出去了。
我有时候会想，这两次"摸不到"，表面上看起来一样，本质上完全不同。
2009 年的摸不到，是条件限制。计算资源稀缺，数据库是需要专人照顾的精密设备，开发没有资格碰。你摸不到，你也不知道里面在发生什么，就像上一篇说的，生产环境对开发完全是黑盒。
2026 年的摸不到，是主动选择。你可以摸到，随时可以在本地跑一个实例，技术条件完全允许。但 Neon 更快，D1 更省，CockroachDB 的高可用不需要你来操心。你把管理权交出去，换来的是时间和精力，去做你真正在乎的事情。
中间那段"摸得到"的窗口——虚拟机、Docker、Postgres.app——反而是个历史上短暂的特殊时期。大概从 2010 年代初到 2020 年代初，也就十年左右，工程师短暂地和数据库住在了同一台机器上。
然后各走各的路了。
PostgreSQL 贯穿了这整条线。
小型机上跑的是它，虚拟机里装的是它，Docker 拉的是 postgres 镜像，Neon 的底层也是它——只是你再也看不到那个进程，看不到那个数据目录，看不到那个 pg_hba.conf。
某种意义上，PostgreSQL 还在。只是它搬家了，搬到了你找不到的地方。
你们的关系没有结束，只是变得更像一个远程的老朋友——你知道它在，偶尔用到，但已经不记得它住在哪里了。