作者用两个生产案例说明如何把「让非法状态无法表示」落到数据建模上。案例一：把连续时间线表示为 List (Date, Date) 会留下空隙和重叠，改为只存切分日期的 Set Date，连续与不重叠约束就天然成立，再切一刀只需往集合里加一个日期。案例二：合约系统把 fixed 与 default 合约都塞进同一张表，结束日期是可空字段，加上按单份合约修改的 API 毫无防护，线上确实出现过合约空缺，排查耗费数小时工程时间；把 default 合约从表中移除、由「没有 fixed 合约」推断得出后，空缺与可选结束日期同时消失。作者认为根源是用 OO 思维把每个概念都物化成一行，把行当作序列化对象而非命题，这会反过来污染整个系统设计。文末给出禁止合约重叠的两种做法：数据库 excludes 约束，或写模型允许重叠、读模型投影时用下一份合约的起始日截断。适合做数据建模与后端 schema 设计的工程师阅读。
作者指出，微服务与非 ACID 数据库流行之际，最容易被忽略的代价是 ACID 事务。文章以「一个用户必须有一个 profile」为约束，展示单库事务如何同时保证原子性与隔离性：创建、外键校验都在一个事务内完成。一旦把 users 与 profiles 拆成两个服务，原子性、隔离性、外键约束全部失效。作者逐一推演失败路径：profile 服务失败会留下裸 user；补写的 delete 回滚本身会失败，或进程断电留下中间态；即使两个服务 100% 可靠，并发线程仍会看到 user 无 profile 并重复创建；外键失效后 profile 可指向已删除或改过的 user ID；定时清理 dangling 数据也仍存在不一致窗口。结论是应用层的补偿逻辑最终等价于重造一个半成品、带 bug 的分布式 ACID 数据库，采用微服务或 NoSQL 之前应先理解自己引入了什么复杂度。适合准备拆分服务或迁移 NoSQL 的后端工程师。
2006 年，作者在纽约杂志数字团队用 MySQL 4 加 Perl 给时装周做分面搜索：秀场图按「2006」「bag」「red」等标签分类，用户可下钻筛选，每个属性还要带精确计数。当时 Solr facets 尚不存在，Autonomy 的计数不对，Endeca 刚出隐身期，三个人的团队只能自己啃 SQL，靠 EXPLAIN、GROUP BY 和反复调 MySQL 服务器参数把延迟压下去。 二十年后作者看到的却是相反趋势：工程师给普通规模的问题上 DynamoDB 这类「行星级」数据库，却对自己正在用的关系库缺乏基本掌握。文中复述一次电商事故——商品列表页要 10 秒以上，且无流量时一样慢，同一页面同时踩了缺索引、ORM 循环逐条查询（单页 200–500 条 SQL）、SELECT 全部列三个坑。作者的主张是：现代 RDBMS 在被证明有罪之前都是清白的，举证责任几乎全在工程师身上；文末给出排障顺序（慢查询日志 → 高频查询 → EXPLAIN → 只取必要列 → 必要时写原生 SQL）与三类反模式。适合后端与数据工程师。
作者列出自己构建软件时遵循的一组原则，主线是让系统更简单：让非法状态无法表示、保证数据一致性、先设计数据再写代码、测量之后再优化。文中用一个数据库例子说明不一致的代价——必须保持 x=y 的两个布尔变量一旦拆到不同库、无法原子更新，数据就多出两种状态，toggle 函数在这些状态下没有正确答案。作者认为一致性是当下最被低估的工程原则，多数问题本质上都是数据不符合预期；他同时主张代码一致性优先于局部「正确」，学习应聚焦 concepts（关系模型、代数数据类型、borrow checker、Curry-Howard 同构）而非 React、Kubernetes 的表层细节。适合做后端与数据系统设计、正在权衡微服务拆分和 schema 取舍的工程师。
作者以多年 CTO 经验主张用 PostgreSQL 统一技术栈，认为它不仅能当关系数据库，还能替代全文检索、文档库、消息队列、时序库、向量库、缓存乃至图数据库。文中引用 Contentful、Instacart、Guardian 的迁移案例，并列出具体机制：tsvector/tsquery 全文检索、GIN 索引、SELECT ... SKIP LOCKED 实现队列、UNLOGGED 表模拟缓存、TimescaleDB 处理时序、pgvector 做向量检索、Apache AGE 提供 openCypher 图查询。适合正在考虑精简基础设施的工程师阅读，但文中缺少基准数字，需自行验证性能边界。
作者借回应《PostgreSQL for Everything》的机会，提出更极端的组合：SQLite 不是玩具，而是把 RDBMS、全文检索、文档存储、队列、时序数据、向量库和缓存合并成一个文件与一次函数调用。文章给出多个可直接照搬的做法：用 BEGIN IMMEDIATE 配合 RETURNING 把表当持久化队列；用 JSON 生成列索引无模式字段；用 sqlite-vec 让混合检索退化成同一个事务里的 JOIN；用 WAL 加 synchronous=OFF 把缓存延迟压到约 1 微秒，低于本地 Redis 的约 100 微秒。它也列出了诚实的边界：SQLite 只有单写者，几十万行/秒的写入和每秒百万点级的时序场景应另选专业系统。适合想减少基础设施组件、重新评估依赖边界的后端与基础设施工程师。
CodeGraph 是一个针对 AI 编码智能体（如 Claude Code、Cursor 等）的本地代码知识图谱工具。它通过 tree-sitter 静态解析源码，将符号关系、调用链和代码结构预先索引至本地 SQLite 数据库，供智能体直接查询，从而替代传统耗时的 grep 和文件读取搜索。根据在 7 个真实项目上的基准测试，集成后平均可降低 25% 的成本、减少 62% 的工具调用，并能实现跨框架路由识别和 iOS/React Native 混合桥接解析。该项目完全本地运行，无需外部服务或 API 密钥，适合追求降低 Token 消耗和提升编码效率的工程师。
ClickHouse解决方案架构师分享十大可落地的最佳实践，涵盖主键设计、数据类型、分区策略、跳过索引、JSON类型、数据摄取、物化视图、系统表、ReplacingMergeTree与JOIN优化。每条实践都基于Amazon评论数据集（1.5亿行）的基准测试，给出量化性能差异：主键顺序错误导致全表扫描，优化后扫描量减少347倍；不必要分区让查询慢46倍；恰当的数据类型压缩存储12%、提速2倍；跳过索引减少80%扫描量；字典查找比常规JOIN快近3倍。全篇强调理解ClickHouse存储与合并机制，用实际数据验证设计决策的影响，适合正在或计划在生产环境使用ClickHouse的工程师对照优化。
ClickHouse 在 Open House 上发布了 ClickStack 可观测性的三大更新：全托管的 ClickStack Cloud（私有预览），AI Notebooks（测试版），以及开源的 ClickStack MCP Server。AI Notebooks 将事故排查设计为持久、可分支的调查工作区，而非单一聊天线程；底层直接调用 ClickStack 优化后的调查原语，每一步查询与推理都可见可编辑。MCP Server 将这些原语暴露给外部 AI 代理，内部基准测试显示工具调用减少 25%，一致性提升 2.5 倍；支持双向操作，代理既能分析也能直接在 ClickStack 中创建仪表盘。文章强调“自带代理”的理念，并指出结构化调查工具与原始 SQL 互补：SQL 是任意探索的逃生舱。所有更新都围绕一个方向：让可观测性工具更协作、更可编程，而不是锁定工作流。适合已用或评估 ClickHouse 做可观测性的基础设施/ SRE 工程师。
本文对比了 OpenTelemetry Collector 与 Rotel 在向 ClickHouse 写入追踪数据时的性能。在相同 8 核主机上，Rotel 实现每秒 370 万 trace span 的吞吐量（每核 46.25 万），是 OTel Collector 的 4 倍以上。性能提升源于三项关键优化：RowBinary 格式下的 JSON 列二进制编码，降低序列化开销；将反序列化迁移至共享线程池，消除 Tokio 任务阻塞及 glibc 内存分配器锁争用；启用快速 LZ4 压缩。测试还揭示了 OTel Collector 在反压下静默丢数据的缺陷。适合大规模可观测性数据管道的架构师与 SRE 参考。
ClickHouse 发布了官方 Agent Skills，一套开源的最佳实践规则集，基于 Anthropic 的 Agent Skills 规范打包了 28 条经工程师和社区验证的 ClickHouse 实操规则，涵盖 Schema 设计、查询优化和数据摄入。执行 npx skills add clickhouse/agent-skills 即可添加到本地环境，AI 助手（如 Claude Code）会自动在需要时调用这些规则，避免常见错误（如错误的 ORDER BY、不可扩展的 JOIN、遗漏物化视图）。仓库使用 Apache 2.0 许可，欢迎社区贡献经验。