家里跑着 PostgreSQL 18：一个按钮触发的真实查询

从按钮到数据库：一次点击背后的完整链路

我点开这个页面的时候，看到的只是一个按钮。按下之前，我的浏览器已经从 Cloudflare 边缘节点拿到了脚本、样式和字体，但数据库那边什么都没有发生。直到我按下那个按钮，一条请求才真正出发，穿过 Cloudflare 的 Worker vinext，再经过 Hyperdrive 的连接池，最后落到我家里的那台 Minisforum mini PC 上 来源：OA。

这条链路比我想象的复杂。Worker 部署在芝加哥附近，离数据库很近，用 node-postgres 执行一个固定查询。请求先被限速，然后进入 Workers VPC 服务 pg-home，这是一条私有路由，没有公共主机名。接下来流量通过 Cloudflare Tunnel 的 home-k3s 隧道从我家拨出，隧道保持 4 条到芝加哥或底特律数据中心的连接，用 QUIC 协议 来源：OA。

到我家之后，cloudflared Pod 接收连接，解析 pg-home.jilles.dev，CoreDNS 把这个名字重写为集群内服务 postgres-prod-rw，这个服务始终指向当前主实例。最终到达 PostgreSQL 18 的 pod，由 CloudNativePG 管理，限制为 2 CPU 和 2 GB 内存 来源：OA。

那台机器有 8 核 Ryzen 9 7940HS，Postgres 还和其他几个应用共享它。单实例，没有副本。我按下按钮到看到结果，中间走过的路径，从我家到芝加哥的隧道、VPC、Worker、Hyperdrive，再回来，全程都是真实的，没有模拟。

安全、可用性与反直觉选择

作者特意强调，这个查询没有任何模拟，结果也没有被缓存。这和我见过的演示不一样，大多数前端演示会造假数据，或者用缓存掩盖延迟。这里按一次按钮就是一次真实查询，页面加载完全不产生数据库负载 来源：OA。

安全性靠反向连接实现。隧道从家里主动拨出，路由器没有开放任何入站端口，外网根本无法直接连进来。TLS 用 Cloudflare Origin CA 证书，在 Postgres 处终止。这种设计让数据库像一台躲在窗帘后面的机器，只有隧道是它伸出去的那只手 来源：OA。

可用性方面，数据库没有副本，备份发送到对象存储。如果家里断电，按钮会告诉你，原文写得很直接：If the power goes out here, the button above will tell you 来源：OA。我不确定这个告知具体怎么实现，可能按钮会变成红色或者显示错误，但作者没有展开。单实例无副本，意味着停电或网络断掉，整个服务就不可用。

作者选了 PostgreSQL 18，还专门在文末列了一个 New in Postgres 18 板块。里面讲的是日历防重复预订，用 PRIMARY KEY (room, hours WITHOUT OVERLAPS) 和 FOREIGN KEY (room, PERIOD hours) 两条规则放在 schema 里，应用层完全不检查，所以没有竞态可输 来源：OA。

多源对比：技术深度与社区关注度的反差

这篇帖子在 Hacker News 上只拿到 1 分，0 条评论 来源：HN。我看完整个链路，觉得奇怪。一个把 Cloudflare Worker、Hyperdrive、Tunnel、k3s、CloudNativePG、PostgreSQL 18 串起来的真实部署，技术密度不算低，社区却一点反应都没有。

可能的解释是，这个项目太个人化了。数据库住在作者家里，跑在一台 mini PC 上，整个页面只有一个按钮。这样的架构对别人参考价值有限，大家没法复制。HN 上常见的是能引发讨论的架构选择，比如数据库上生产、无服务器争议，而家里跑 Postgres 属于个人实验，没有共性。

另外一个因素是演示方式。页面只给一个按钮，按下就执行固定查询，没有面板、没有图表、没有复杂交互。这种极简呈现让文章看起来像玩具，虽然背后的链路一点不玩具。我翻到 New in Postgres 18 部分，看到那个日历冲突示例，才意识到作者是在用真实场景验证新特性。

1 分 0 评论的结果，我倾向于认为不是技术不行，是话题太小众。作者没有在文末呼吁讨论，也没有贴性能数字，就是展示了一条链路，然后说，我家的数据库能响应你的点击。这种自信不靠社区点赞来背书。

原文：

Database Lives in My House · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月3日