PGSimCity 的吸引力很直接：它把 PostgreSQL 的内部机制做成了浏览器里的 3D 城市。Clients、backends、shared buffers、WAL、checkpoints、autovacuum、replication 和 bloat 不再只是架构图上的方框，而是可以观察的移动部件。

浏览器中的开源 PostgreSQL 数据库城市模型

但这不等于可以盲目信任。README 说得很清楚：这是 prototype，simulation 和 explanations 都可能有错误；它是 model，不是 emulator。浏览器里没有运行 PostgreSQL source code，数字也经过缩放，方便人观察。正因为作者把限制说出来，这个项目才更值得试。

Live demo 放在 GitHub Pages，NikolayS/PGSimCity 仓库以 Apache-2.0 发布。package metadata 现在显示 0.6.0，但 README 仍然用 v0.1 prototype 的语气描述项目。这不是大问题，更像是 HN 走红后项目快速变化的痕迹。

检查时，仓库有 62 stars、2 forks 和 2 个 open issues。7 月 27 日的最新 commits 已经在改进 follow one query across the whole city 和 mode exit。我们也做了本地验证：在 Node 20.20.2 下，npm install、npm run typecheck 和 npm run build 都通过了。技术栈很轻：three.js r185、TypeScript、Vite，runtime dependency 只有 three。

PGSimCity 最有用的地方，是给人第一张 mental map。很多 backend developers 会写 SQL，却没有直观看过 workload 如何影响 WAL、buffers 或 autovacuum。视觉模型不能替代官方文档或 DBA，但能让这些概念不再那么抽象。

Hacker News 讨论在检查时有 411 points 和 41 comments。反馈很具体：想法很棒，但 UI 太吵，camera controls 需要改进，tour 应该更慢，最好能输入一条 query，再一路看它经过 parsing、planning、execution 和 storage。这说明项目下一步不只是“更漂亮”，而是更会教学。

最大风险是准确性。交互模型比静态图更有说服力。如果它把细节简化错了，用户会把错误当成经验记住。所以作者邀请 PostgreSQL experts 提 issues 和 pull requests 很重要。没有这种 review，它只是好看的 demo；有了 review，它才可能变成可靠的教育工具。

AI-assisted 这个点也值得提，但不该抢走主题。作者在 HN 中说，项目从一个 prompt 和对 Opus 5 的好奇开始，并大量借助模型。真正的问题在后面：coding agents 可以很快做出野心很大的 prototype，但可信度要靠 open source community review 建立。

谁应该试？使用 PostgreSQL 的 backend developers、SRE/DBA teams、数据库课程作者，以及想解释 WAL、checkpoints、autovacuum 的人。谁要谨慎？任何想用它直接指导 production tuning 的人。生产问题仍然要看 official docs、metrics、logs 和专家经验。

更大的信号不只属于 Postgres。Kubernetes、compilers、storage engines、CPUs 和 runtimes 都有同样的文档空白：静态图太薄，源码又太重。Explorable models 可以填补中间地带，但前提是它们像软件一样被 review，而不是像漂亮的信息图一样被消费。