A personal blog about programming, tools, and continuous learning.
很多初涉软件工程的开发者，对“开源”（Open Source）往往存在两种极端的误解：一种是把它神秘化，觉得必须像 Linus Torvalds 一样徒手写出操作系统内核，或者有能力给 PyTorch、Kubernetes 核心提炼算法，才有资格做开源；另一种则是把它极简甚至庸俗化，以为只要在本地写个玩具 Demo，顺手 git push 到 GitHub，把仓库设为 Public，就叫做“做开源”。
现实中的开源既不神秘，也不廉价。开源不是单纯的代码公开，而是一套跨越时区、语言和组织的现代软件工程与异步协同范式。
在大多数后端开发者的日常认知里，数据库日志（无论是 MySQL 的 Binlog、InnoDB Redo Log，还是 PostgreSQL 的 WAL）始终扮演着一个“工具人”的角色：
在这些传统场景中，日志永远是“二等公民”。数据库真正的“本体”依然是磁盘上那堆沉重、易碎、被原地覆写（in-place update）的数据页（Data Pages / Tablespace）。正因为数据页与特定的机器磁盘死死绑在一起，数据库的扩缩容、高可用切换、快照备份才变得如此笨重。
开源云原生数据库 Neon 带来的最深刻变革，表面上看是“让 PostgreSQL 能够自动休眠（Scale-to-Zero）”，但其底层真正的架构革命，恰恰在于对数据库预写式日志（WAL / Binlog）的颠覆性重构——它践行了分布式系统领域最优雅的哲学：“The Log IS the Database”（日志即数据库）。
本文将从传统数据库日志的工程困境出发，深度剖析 Neon 是如何将日志从辅助同步产物提升为核心存储基石，并由此解锁分布式共识、按日志重构页面、Git 式秒级分支与无锁时间旅行的。
很多人第一次听到 CQRS，会把它理解成“写主库、读从库”。这不算错，但主从读写分离解决的是数据库读压力，CQRS 多给了一层自由度：写侧围绕业务正确性建模，读侧围绕查询场景重新建模，两边可以用不同的存储，数据结构也不必相同。
我习惯把它概括成六个字：写事实，读投影。