数据库

• 1: MySQL 9.7：还是那碗冷饭
• 2: 续命 MinIO：承诺兑现
• 3: 把 Agent 的状态放进数据库
• 4: 360安全龙虾，把自己的泛域名私钥打进了安装包
• 5: 一场辩论之后，认真聊聊“本体论”
• 6: InsForge：为 Vibe Coding 而生的 Supabase
• 7: 用 AI 当由头裁了4000人，但程序员的需求涨了11%
• 8: Palantir 的“本体论”骗局
• 9: 重新设计数据密集型应用
• 10: 从麦克卢汉的视角看 AI：当媒介不再延伸人体，而是延伸人脑
• 11: 新年，聊聊 AI 将带来的变化
• 12: DDIA 第二版翻完了：一个跨越八年的 AI 寓言
• 13: MinIO 已死，MinIO 复生
• 14: 写代码一文不值的时代，什么才值钱？
• 15: Agent 的护城河：强龙不压地头蛇
• 16: AI 撕掉了软件的皮
• 17: AI 时代，新程序员将何去何从？
• 18: 软件世界大熔断：当翻译层被压扁
• 19: AI Agent 的操作系统时刻
• 20: Claude Code 可观测性怎么做？
• 21: Andy Pavlo：2025 数据库世界年度总结
• 22: Claude Code 免翻上手教程
• 23: 2025 年度数据库世界总结：石破天 vs Andy Pavlo 对谈录
• 24: Agent 需要什么样的数据库？
• 25: MySQL 与白酒：互联网行业的服从测试
• 26: Victoria：吊打业界的可观测性全家桶来了
• 27: MinIO 已死，谁能接盘？
• 28: MinIO 已死
• 29: 当答案唾手可得，问题成为新货币
• 30: 聊聊开源软件供应链信任问题
• 31: 原地报废：不要在生产环境用 Docker 跑 PostgreSQL！
• 32: DDIA 第二版中文翻译
• 33: 专栏：数据库老司机
• 34: 懂车帝暴打智驾，懂库帝在哪里
• 35: Google AI 工具箱：生产级数据库 MCP 来了？
• 36: AI 时代的数据库与 DBA 将何去何从
• 37: 别争了，AI 时代数据库已经尘埃落定
• 38: 开放数据标准：Postgres，OTel，与 Iceberg
• 39: 小数据的失落十年：分布式分析的错付
• 40: OpenAI：将 PostgreSQL 伸缩至新阶段
• 41: Etcd 坑了多少公司？
• 42: AI 时代，软件从数据库开始
• 43: MySQL vs PostgreSQL @ 2025
• 44: 数据库火星撞地球：当 PG 爱上 DuckDB
• 45: 对比 Oracle 与 PostgreSQL 事务系统
• 46: 数据库即业务架构
• 47: 七周七数据库（2025年）
• 48: 使用一条 SQL 计算扑克24点
• 49: 自建 Supabase：创业出海的首选数据库
• 50: 面向未来数据库的现代硬件
• 51: MySQL 还有机会赶上 PostgreSQL 吗？
• 52: 开源“暴君”Linus 清洗整风
• 53: 先优化碳基 BIO 核，再优化硅基 CPU 核
• 54: MongoDB 没有未来：好营销救不了烂芒果
• 55: MongoDB：现在由 PostgreSQL 强力驱动？
• 56: 瑞士强制政府软件开源
• 57: MySQL 安魂九霄，PostgreSQL 驶向云外
• 58: CVE-2024-6387 SSH 漏洞修复
• 59: Oracle 还能挽救 MySQL 吗？
• 60: Oracle 最终还是杀死了 MySQL
• 61: MySQL 性能越来越差，Sakila 将何去何从？
• 62: 20刀好兄弟 PolarDB：论数据库该卖什么价？
• 63: 国产数据库到底能不能打？
• 64: Redis 不开源是“开源”之耻，更是公有云之耻
• 65: MySQL 正确性竟如此垃圾？
• 66: 数据库应该放入 K8S 里吗？
• 67: 专用向量数据库凉了吗？
• 68: 数据库真被卡脖子了吗？
• 69: EL 系操作系统发行版哪家强？
• 70: 基础软件需要什么样的自主可控？
• 71: 正本清源：技术反思录
• 72: 数据库需求层次金字塔
• 73: 分布式数据库是不是伪需求？
• 74: 微服务是不是个蠢主意？
• 75: 是时候和 GPL 说再见了
• 76: 容器化数据库是个好主意吗？
• 77: 理解时间：闰年闰秒，时间与时区
• 78: 理解字符编码原理
• 79: 并发异常那些事
• 80: 区块链与分布式数据库
• 81: 一致性：过载的术语
• 82: 为什么要学习数据库原理

1 - MySQL 9.7：还是那碗冷饭

MySQL 9.7 作为 9.x 系列第一个 LTS 版本，向量能力依旧是花架子，迟到多年的优化器默认关闭，三年 Innovation Release 攒出来的答卷仍然乏善可陈。 阅读全文

2 - 续命 MinIO：承诺兑现

pgsty/minio 在三天内修复并发布多项高危漏洞补丁。兑现了“继续维护开源 MinIO 分支”的承诺。 阅读全文

3 - 把 Agent 的状态放进数据库

把 AI Agent 的工作目录、配置和记忆放进 PGFS 挂载目录，本质上就是把状态放进 PostgreSQL。 这样你不仅获得 PITR“时光机”，还能让多 Agent、多设备共享同一套工作空间与记忆。 阅读全文

4 - 360安全龙虾，把自己的泛域名私钥打进了安装包

360 刚发布的 AI Agent 产品“360安全龙虾”，被发现公开安装包中直接包含 *.myclaw.360.cn 泛域名证书私钥；进一步的公开验证与本地复现还暴露出 该证书吊销链路在 OCSP 返回结果上的一致性问题。 阅读全文

5 - 一场辩论之后，认真聊聊“本体论”

Palantir 的 Ontology 在技术上就是数据建模，但更值得认真讨论的是：它如何借“本体论”的哲学光环包装系统集成与数据建模，以及为什么这套叙事在中国技术生态中极易演化为新一轮概念泡沫。 阅读全文

6 - InsForge：为 Vibe Coding 而生的 Supabase

InsForge 试图把数据库、认证、文件存储和语义层一起打包成一个更适合 AI Agent 的后端底座，像一个专为 Vibe Coding 设计的 Supabase。 阅读全文

7 - 用 AI 当由头裁了4000人，但程序员的需求涨了11%

AI 正在被用作裁员叙事，但软件工程的总需求并未消失，而是在更大范围扩散。真正改变格局的，是门槛下降后被释放的二阶需求。 阅读全文

8 - Palantir 的“本体论”骗局

Ontology 就是数据库建模。“本体论”这个词唯一的作用，就是让不懂数据库的人觉得这是个新东西，然后心甘情愿地为旧东西付出一千倍的价格。 阅读全文

9 - 重新设计数据密集型应用

原文链接：https://www.youtube.com/watch?v=UHdPnubbzBI

本文由 Martin Kleppmann 撰写，聊到了关于《设计数据密集型应用》第二版的一些内容。以及一些关于数据密集型应用设计的思考。

阅读全文

10 - 从麦克卢汉的视角看 AI：当媒介不再延伸人体，而是延伸人脑

用麦克卢汉的“媒介即讯息”“延伸与截肢”“冷热媒介”“后视镜效应”“媒介四定律”解剖 AI，讨论其对人类认知习惯、理解能力与社会结构的深层影响。 阅读全文

11 - 新年，聊聊 AI 将带来的变化

AI 正在以远超历史经验的速度重塑知识工作。真正的挑战不是“会不会用 AI”，而是能否在缓冲期结束前完成认知与能力迁移。 阅读全文

12 - DDIA 第二版翻完了：一个跨越八年的 AI 寓言

一个上午用 codex 翻译完 DDIAv2，相比八年前三个月手工精翻，AI 的能力，在同一本书上形成了鲜明的对照。 阅读全文

13 - MinIO 已死，MinIO 复生

MinIO 仓库正式归档并彻底放弃维护，开源对象存储用户将何去何从？AI Agent 如何助力 MinIO 起死回生？ 阅读全文

14 - 写代码一文不值的时代，什么才值钱？

在代码产能被 AI 极大放大之后，真正稀缺的能力正在从“写代码”转向“设计与验收”。本文基于实战经验，总结了用 Codex 与 Claude 协作交付高质量软件的流程与判断。 阅读全文

15 - Agent 的护城河：强龙不压地头蛇

一个熟悉环境的普通人，会比来到陌生环境的天才更能干。没有上下文的智力是空转的。没有 Runtime 的 Agent 是虚浮的。 阅读全文

16 - AI 撕掉了软件的皮

软件股暴跌，谁能幸存？谁会崛起？AI 撕掉了软件的皮，露出了数据库的骨。市场不是在错杀，而是在分化定价。 阅读全文

17 - AI 时代，新程序员将何去何从？

我们还要招应届大学生吗？在 AI 和老司机的双重夹击下，新程序员的出路在哪里？—— 用对工具、主动出击、找对师傅。 阅读全文

18 - 软件世界大熔断：当翻译层被压扁

SaaS 与流程软件已死，从 APP 与 GUI 到 Agent，Database，CLI。 阅读全文

19 - AI Agent 的操作系统时刻

我们正在见证一个"AI 操作系统"的诞生。LLM 是新 CPU，Context 是新内存，Agent 是新应用。那么 OS 会是什么？理解这个类比，也许能帮助我们预测未来 2-3 年基础设施的演化路径 —— 以及找到真正的机会所在。 阅读全文

20 - Claude Code 可观测性怎么做？

获取 Claude Code 的详细 OTEL 日志与指标，放入 Victoria 全家桶，放进并通过 Grafana 监控面板呈现。 阅读全文

21 - Andy Pavlo：2025 数据库世界年度总结

图灵奖得主 + CMU 教授：2025 数据库圈最犀利的一场对话。关于数据库，LLM，Agent，AI 落地的实际效果，程序员的职业生涯…… 阅读全文

22 - Claude Code 免翻上手教程

如何不翻墙下载安装使用 Claude Code？如何用 Claude 十分之一的成本实现近似的效果？一行命令免翻装好 CC！以及 GLM 4.7 到底能不能吊打 Claude？ 阅读全文

23 - 2025 年度数据库世界总结：石破天 vs Andy Pavlo 对谈录

图灵奖得主 + CMU 教授：2025 数据库圈最犀利的一场对话。关于数据库，LLM，Agent，AI 落地的实际效果，程序员的职业生涯…… 阅读全文

24 - Agent 需要什么样的数据库？

AI Agent 的瓶颈不在数据库内核，而在上层整合。肌肉记忆（库内计算）、联想记忆（向量+图谱融合）、试错魄力（Git for Data）将成为关键，不过这些能力不需要新引擎。 阅读全文

25 - MySQL 与白酒：互联网行业的服从测试

互联网的 MySQL 就像中国的白酒：明明很难喝，却在文化规训下成了琼浆玉液，本质都是一种服从测试。 阅读全文

26 - Victoria：吊打业界的可观测性全家桶来了

Victoria 是朴实无华的强悍— — 用几分之一的资源，实现 Prometheus + Loki 几倍的效果。Pigsty v4.0 将全面采用 Victoria 全家桶。 阅读全文

27 - MinIO 已死，谁能接盘？

MinIO 进入维护模式，有什么替代品？Ceph、RustFS、SeaweedFS、Garage 各有各的问题。老冯把这些方案都打好了包挨个试了一遍，总结一句话：没有完美替代。 阅读全文

28 - MinIO 已死

MinIO 官方宣布开源项目进入"维护模式"，基本上宣告了 MinIO 作为一个开源项目的死亡。屠龙勇者成为新的恶龙——MinIO 是如何从 S3 开源替代变成一家普通的商业软件公司的。 阅读全文

29 - 当答案唾手可得，问题成为新货币

答案正在贬值，提问的能力决定了你在 AI 时代的位置。凯文·凯利预言成真：当答案成为商品时，好的问题就是新的财富。毕加索早在1968年就说过：计算机毫无用处，它们只能给你答案。 阅读全文

30 - 聊聊开源软件供应链信任问题

在严肃的生产环境里，你不能依赖一个明确说"我不提供任何保证"的上游。当别人告诉你"别指望我"，最好的回应是"那我自己来"。从 TUNA 镜像站的争议谈开源软件供应链信任问题。 阅读全文

31 - 原地报废：不要在生产环境用 Docker 跑 PostgreSQL！

大量用官方 Docker Postgres 镜像的用户在最近小版本升级中翻车踩雷。早在2019年老冯就警告过不要在生产环境用容器运行 PostgreSQL，因为你极大概率会遇上一堆物理机/虚拟机上根本不存在的麻烦。 阅读全文

32 - DDIA 第二版中文翻译

曾经的互联网名著 DDIA——设计数据密集型应用第二版已经发布到第十章了。老冯用 Claude Code 翻译成中文，并用 Hugo/Hextra 重构成易读的网页版。第二版新增了向量数据库 HNSW 索引等内容，温故知新。 阅读全文

33 - 专栏：数据库老司机

数据库领域充满着太多胡言乱语与不实营销，数据库老司机带您拨云见日，穿透迷糊，直击行业核心与本质。 阅读全文

34 - 懂车帝暴打智驾，懂库帝在哪里

懂车帝搞的智驾评测视频让一众国产自动驾驶现了原形，封闭高速真实测试结果全军覆没，只有特斯拉能打。什么时候国产数据库和云计算也能有个"封闭高速"给大家上来溜一溜，拆穿这股满嘴跑火车的行业歪风？ 阅读全文

35 - Google AI 工具箱：生产级数据库 MCP 来了？

Google 推出了一个针对数据库的 MCP 工具箱 GenAI Toolbox，通过封装参数模板 SQL 的方式，显著提高了数据库 MCP 的实用性与安全性。不同于以前那种直接把整个数据库对 Agent 开放的粗暴做法，这可能是第一个生产可用的方案。 阅读全文

36 - AI 时代的数据库与 DBA 将何去何从

OLTP 与 OLAP 谁先被 AI 革命？一体化还是专业化，如何选型？AI 时代的 DBA 该何去何从？来自 HOW 2025 大会圆桌讨论的观点整理：OLAP 岗位正被 NL2SQL 替代，而 DBA 因语料稀缺暂时安全。 阅读全文

37 - 别争了，AI 时代数据库已经尘埃落定

AI 时代的数据库格局已经尘埃落定。Databricks 收购 Neon，Snowflake 收购 CrunchyData，OpenAI 传闻收购 Supabase——资本市场对 PostgreSQL 标的密集出手，PG 已成为 AI 时代的默认数据库。 阅读全文

38 - 开放数据标准：Postgres，OTel，与 Iceberg

数据世界正在浮出水面的三大新标准：Postgres、Open Telemetry，以及 Iceberg。Postgres 已是事实标准，OTel 和 Iceberg 尚在成长，但它们具备当年让 Postgres 走红的同样配方——关键在于开源的姿势本身。 阅读全文

39 - 小数据的失落十年：分布式分析的错付

如果2012年 DuckDB 问世，也许那场数据分析向分布式架构的大迁移根本就不会发生。在2012年的 MacBook 上运行 TPC-H 评测显示，数据分析确实在分布式架构上走了十年弯路。数据其实没那么大。 阅读全文

40 - OpenAI：将 PostgreSQL 伸缩至新阶段

原文链接：https://www.pgevents.ca/events/pgconfdev2025/schedule/session/433-scaling-postgres-to-the-next-level-at-openai/

在 PGConf.Dev 2025大会上，来自 OpenAI 的 Bohan Zhang 分享了 OpenAI 在 PostgreSQL 上的最佳实践。在 OpenAI，他们使用一写多读的未分片架构，证明了 PostgreSQL 在海量读负载下也可以伸缩自如。 阅读全文

41 - Etcd 坑了多少公司？

因为 Etcd 而翻车的公司并非少数。Etcd 有一个坑爹的默认设计：写满2GB 数据就挂了。如果你在自己折腾 Kubernetes 或使用 Patroni 做 PostgreSQL 高可用，大概率会在这上面翻车。 阅读全文

42 - AI 时代，软件从数据库开始

未来的软件形态是 Agent + 数据库，没有前后端中间商，Agent 直接 CRUD。微软 CEO 纳德拉预言 SaaS 已死，软件从数据库开始。数据库技能相当保值，PostgreSQL 将成为 AI Agent 时代的核心数据库。 阅读全文

43 - MySQL vs PostgreSQL @ 2025

在2025年的当下，MySQL 无论是在功能特性集、质量正确性、性能表现还是生态与社区上都被 PostgreSQL 拉开了差距，而且这个差距还在进一步扩大中。本文从功能、性能、质量、生态来全方位对比两者。 阅读全文

44 - 数据库火星撞地球：当 PG 爱上 DuckDB

老冯很看好"DuckDB + PostgreSQL 深度融合"这条路径，它可能会引爆数据库世界下一场"火星撞地球"式的变革。相比折腾分布式 DuckDB，这才是更有前景的方向。 阅读全文

45 - 对比 Oracle 与 PostgreSQL 事务系统

PG 社区开始骑在 Oracle 头上输出了。Cybertec 专家对比 Oracle 和 PostgreSQL 事务系统的特性，帮助用户理解两者差异，为从 Oracle 迁移到 PostgreSQL 提供关键参考，避免性能和数据完整性问题。 阅读全文

46 - 数据库即业务架构

数据库是业务架构的核心，这是不言自明的共识。但如果更进一步，将数据库作为业务架构本身，将业务逻辑、Web Server 甚至整个前后端都放入数据库中，又会擦出怎样的火花？ 阅读全文

47 - 七周七数据库（2025年）

原文链接：https://matt.blwt.io/post/7-databases-in-7-weeks-for-2025/

PostgreSQL 是无聊数据库之王？2025年值得深入学习的七个数据库：PostgreSQL、SQLite、DuckDB、ClickHouse、FoundationDB、TigerBeetle、CockroachDB，每个都值得花一周时间研究。 阅读全文

48 - 使用一条 SQL 计算扑克24点

虽然有趣，但是很鸡贼的题目，用 SQL 计算扑克24点。PostgreSQL 的正解。 阅读全文

49 - 自建 Supabase：创业出海的首选数据库

Supabase 是以 PostgreSQL 为核心的开源 BaaS，提供身份认证、Realtime、Edge Functions、对象存储，以及由数据库模式生成的 REST API；按需启用 pg_graphql 后也可提供 GraphQL API。

当你需要掌控数据与基础设施、满足隔离或合规要求，或者希望自行选择 PostgreSQL 版本与扩展时，可以考虑自托管。Supabase 的 官方自托管文档 推荐 Docker，并明确指出自托管方负责服务器、安全加固、数据库维护、高可用、备份和监控。Pigsty 是独立的社区集成，目前不在该官方页面的社区项目列表中。

Pigsty v4.5 的 supabase 模板把有状态组件交给 Pigsty 管理：PostgreSQL 由 PGSQL 模块托管，对象存储由 MINIO 模块当前部署的 Silo 提供；Auth、Storage、Realtime、Studio 等无状态组件使用 Docker Compose 运行。模板支持 PostgreSQL 15-18（默认 18），并可使用 Pigsty 当前收录的 575 个 PostgreSQL 扩展。

本文原发于 2024-11-25，命令和事实已于 2026-08-14 按 Pigsty v4.5 当前源码重新校准。持续更新的完整说明位于 Supabase 企业级自建；该参考页是部署参数与操作步骤的唯一维护入口。

快速开始

完整 Supabase 栈至少需要 2 核 CPU 与 4 GB 内存，建议 4 核与 8 GB 以上。准备受支持的 Linux 系统，下载当前公开稳定版 Pigsty，生成配置后务必先修改域名、密码和密钥：

curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./configure -c supabase
vi pigsty.yml
./deploy.yml
./docker.yml -l supabase
./app.yml -l supabase

deploy.yml 是标准单机部署入口；docker.yml 与 app.yml 使用 -l supabase 限定目标组。安装完成后，可以通过 http://<node-ip>:8000 访问 Supabase Studio。模板中的 supabase / pigsty 仅为演示凭据，生产环境不得保留。

请在运行前核对以下事项：

• JWT_SECRET、ANON_KEY、SERVICE_ROLE_KEY、Dashboard、Logflare、Realtime 与 S3 凭据均已重新生成；
• API_EXTERNAL_URL 保留 /auth/v1 后缀，而 SITE_URL 与 SUPABASE_PUBLIC_URL 使用站点根 URL；
• PostgreSQL 业务用户密码与 POSTGRES_PASSWORD 一致，对象存储用户与 S3 配置一致；
• 公网或 OAuth 场景使用真实域名与 HTTPS；
• 已用 pig pb info 验证备份，并实际做过恢复演练。

具体变量、长度约束、模板路径和重新加载命令见 安全加固。

架构与能力边界

Pigsty 模板不启动上游 Compose 的 db 与 supavisor 容器。无状态容器直接访问 Pigsty 管理的 PostgreSQL 服务；单节点模板默认使用 5436 服务端口，它始终路由到当前主库。

Logflare / Analytics 使用独立的 _supabase 数据库及 _analytics 模式。Studio 的 Query Performance 通过 extensions 模式中的兼容对象读取 pg_stat_statements，而实际扩展仍位于 monitor 模式，以兼容 Pigsty 监控。

默认单节点模板适合评估、小型工作负载与起步部署，但它不是高可用拓扑。若只有一台服务器，建议使用外部 S3 同时承载 Supabase Storage 与 PostgreSQL 备份，以降低本机整体故障风险。实际 RPO 取决于可恢复备份、WAL 归档和对象存储状态，不能用固定数据量承诺。

生产级高可用通常需要：

• 至少三节点的 ETCD DCS；
• 多节点 PostgreSQL，并按目标明确选择同步策略；
• 多节点 Silo 或独立的高可用 S3 服务；
• 多副本 Supabase 无状态容器，以及 DNS、VIP 或 HAProxy 接入；
• 对备份恢复、故障切换和证书续期进行周期性演练。

默认 norm 预设的目标 RTO 是 45 秒以内，异步复制不承诺 RPO=0。若目标是 RTO 低于 30 秒且已确认事务在切换时不丢失，需要显式使用 fast RTO 预设与 crit.yml 严格同步策略，并以实际故障演练结果为准。详情见 高可用 与 部署规划。

域名、对象存储与邮件

生产部署应在 infra_portal.supa 配置域名、反向代理和证书，并同步设置 apps.supabase.conf 下的三个外部 URL。使用 make cert 申请证书后，通过下列命令只更新 Supabase 应用配置与容器：

./app.yml -l supabase -t app_config,app_launch

Supabase Storage 可以连接 Silo、云 S3 或其他 S3 兼容服务。切换 PostgreSQL 的 pgBackRest 仓库是有状态变更：必须先检查现有备份，再在明确授权后运行目标限定的 ./pgsql.yml -t pg_backup -l <cluster>，最后立即创建并验证新仓库中的全量备份。旧仓库数据不会自动迁移，详见 切换备份仓库。

Auth 发信需要生产可用的 SMTP 服务。SMTP_HOST 只填写主机名，端口单独写入 SMTP_PORT；修改后同样用目标限定的 app.yml 重新加载。

完整配置样例、阿里云 OSS 字段和 SMTP 参数见 Supabase 企业级自建。

为什么选择 Pigsty

Supabase 官方当前预配置 50 多个扩展，具体清单随平台更新；Pigsty v4.5 的扩展目录包含 575 个条目，并提供 Supabase 使用的 pg_graphql、pg_jsonschema、wrappers、index_advisor、pg_net、supabase_vault、pgjwt、pgsodium、supautils 与 plan_filter 等包。

自建的价值不是“零运维”，而是把版本、扩展、数据、备份和可用性策略的决定权交回用户。相应地，服务器维护、安全补丁、密钥管理、容量规划、备份验证和故障演练也由部署方负责。开始前请通读 Supabase 参考手册、安全指南 与 备份机制。

50 - 面向未来数据库的现代硬件

原文链接：https://transactional.blog/blog/2024-modern-database-hardware

本文是一篇关于硬件发展如何影响数据库设计的综述，介绍了网络、存储、计算三个领域的关键硬件进展。充分利用好新硬件而非折腾分布式，才是数据库内核发展的正路。 阅读全文

51 - MySQL 还有机会赶上 PostgreSQL 吗？

原文链接：https://www.percona.com/blog/can-mysql-catch-up-with-postgresql/

Percona 创始人 Peter Zaitsev 讨论 MySQL 是否还能跟上 PostgreSQL 的脚步。作为 MySQL 生态的主要扛旗者，Percona 的看法在相当程度上代表了 MySQL 社区的想法，这篇文章值得每个关注数据库发展的人阅读。 阅读全文

52 - 开源“暴君”Linus 清洗整风

Linus 踢出了几位俄罗斯籍开发者，引发开源世界一片哀嚎。但 Linux 是 Linus 的个人项目，三十年前是，现在也依然是。Linux 社区本质是帝制的，而 Linus 本人就是最早且最成功的技术独裁者。 阅读全文

53 - 先优化碳基 BIO 核，再优化硅基 CPU 核

原文链接：https://world.hey.com/dhh/optimize-for-bio-cores-first-silicon-cores-second-112a6c3f

程序员是昂贵稀缺的生物计算核心，是软件成本的锚钉。硅制计算内核丰富而成本不断下降，而生物核却日益稀缺昂贵。因此优化 CPU 核之前，请优先考虑优化生物核——这正是 Ruby on Rails 的设计哲学。 阅读全文

54 - MongoDB 没有未来：好营销救不了烂芒果

MongoDB 在诚信上劣迹斑斑，在产品和技术上乏善可陈，在正确性、性能、功能上被 PostgreSQL 吊打，开发者口碑崩塌，热度下滑，股价腰斩，亏损扩大。碰瓷引战 PG，好营销也救不了它。 阅读全文

55 - MongoDB：现在由 PostgreSQL 强力驱动？

MongoDB 3.2的分析子系统竟然是一个嵌入式的 PostgreSQL 数据库？由 MongoDB 的合作伙伴发出的血泪控诉与吹哨故事，揭露了 MongoDB 对待生态伙伴的态度和一些黑历史。 阅读全文

56 - 瑞士强制政府软件开源

瑞士政府通过开源立法走在时代前沿，强制要求公共部门使用开源软件。真正的自主可控根源在于"开源社区"，而不是某些民族主义式的国产软件。公共资金，公共代码。 阅读全文

57 - MySQL 安魂九霄，PostgreSQL 驶向云外

MySQL 9.0终于发布，距离上一次大版本更新已经过去八年。然而这个空洞无物的所谓"创新版本"犹如一个恶劣的玩笑，宣告着 MySQL 正在死去。Percona CEO 也表示：有了 PostgreSQL，谁还需要 MySQL 呢？ 阅读全文

58 - CVE-2024-6387 SSH 漏洞修复

CVE-2024-6387 是一个严重的 OpenSSH 漏洞，影响 EL9、Ubuntu 22.04、Debian 12等较新版本操作系统。老系统如 CentOS 7.9、Ubuntu 20.04因 OpenSSH 版本老反而逃过一劫，请用户及时更新修复。 阅读全文

59 - Oracle 还能挽救 MySQL 吗？

原文链接：https://www.percona.com/blog/can-oracle-save-mysql/

Percona 创始人 Peter Zaitsev 在官方博客上公开表达了对 MySQL 及其知识产权属主 Oracle 的失望，以及对版本越高性能越差的不满。作为 MySQL 生态的主要扛旗者，Percona 的公开表态是一个值得关注的信号。 阅读全文

60 - Oracle 最终还是杀死了 MySQL

原文链接：https://www.percona.com/blog/is-oracle-finally-killing-mysql/

Peter Zaitsev 是 MySQL 生态重要公司 Percona 的创始人，他撰文痛批 Oracle 的作为与不作为杀死了 MySQL。约15年前 Oracle 收购了 Sun 从而拥有了 MySQL，当时关于 Oracle 何时会"扼杀 MySQL"的讨论此起彼伏，如今一语成谶。 阅读全文

61 - MySQL 性能越来越差，Sakila 将何去何从？

原文链接：https://www.percona.com/blog/sakila-where-are-you-going/

MySQL 版本越高性能反而越差？Percona 监控发现从5.7迁移到8.x 的步伐明显缓慢。在 PostgreSQL 高歌猛进吞噬数据库世界的同时，MySQL 的性能和功能被甩开越来越远。云厂商白嫖是主要原因之一。 阅读全文

62 - 20刀好兄弟 PolarDB：论数据库该卖什么价？

PolarDB 数据库每节点许可证只卖130块？国内 IT 已经卷到这个阶段了吗？今天来聊聊商业数据库、开源数据库、云数据库、国产数据库的公允价格到底是多少。 阅读全文

63 - 国产数据库到底能不能打？

国产数据库到底能不能打？这是个得罪人的问题，不妨用数据说话。本文通过流行度等指标分析数据库生态格局，帮助读者建立更为准确的比例感认知，了解国产数据库在全球市场中的真实位置。 阅读全文

64 - Redis 不开源是“开源”之耻，更是公有云之耻

Redis 从7.4起使用 RSALv2 与 SSPLv1，不再满足 OSI 关于开源软件的定义。这不是 Redis 的耻辱，而是开源/OSI 的耻辱，更是公有云厂商白嫖社区成果的耻辱。当下软件自由的头号敌人是公有云服务。 阅读全文

65 - MySQL 正确性竟如此垃圾？

MySQL 的事务 ACID 存在缺陷，且与文档承诺不符。JEPSEN 测试揭示 MySQL 的可重复读隔离级别既不原子也不单调，连基本的单调原子视图都不满足。这可能导致严重的正确性问题，使用时请务必谨慎。 阅读全文

66 - 数据库应该放入 K8S 里吗？

数据库是否应该放入 Kubernetes 里，到今天仍然是一个充满争议的话题。K8S 在无状态应用管理上非常趁手，但处理有状态服务特别是数据库时有本质局限性。本文深入探讨为什么将数据库放入 K8S 不是明智选择。 阅读全文

67 - 专用向量数据库凉了吗？

向量存储检索是个真需求，然而专用向量数据库已经凉了。小微需求 OpenAI 亲自下场解决了，标准需求被加装向量扩展的现有成熟数据库抢占。想靠讲 AI 故事做成一个产业已经是不可能了。 阅读全文

68 - 数据库真被卡脖子了吗？

很多"国产数据库"就是烂泥扶不上墙的残次品，信创约等于 IT 预制菜进校园。用户捏着鼻子迁移，开发者假装在卖力。基础软件行业其实没人卡脖子，真卡脖子的都是所谓"自己人"。 阅读全文

69 - EL 系操作系统发行版哪家强？

RHEL 系列操作系统发行版兼容水平：RHEL = Rocky ≈ Anolis > Alma > Oracle » Euler。推荐使用 RockyLinux 8.8，有国产化要求可以使用 Anolis 8.8。CentOS 7.9明年 EOL，是时候升级 OS 了。 阅读全文

70 - 基础软件需要什么样的自主可控？

当我们说自主可控时，到底在说什么？运维自主可控与研发自主可控，国家/用户真正需要的自主可控是前者，而不是华而不实的"自研"。国家的需求很简单：打仗吃制裁后，现有系统还能不能继续跑起来。 阅读全文

71 - 正本清源：技术反思录

降本增效的主旋律触发了所有技术的价值重估，当然也包括数据库。本系列将评述数据库领域热点技术，并对其在当下的利弊权衡发出灵魂拷问：云数据库、分布式数据库、微服务、K8S 容器化等技术，究竟是真需求还是伪需求？ 阅读全文

72 - 数据库需求层次金字塔

与马斯洛需求金字塔类似，用户对数据库的需求也有递进的层次：功能正确性、安全备份、高可用监控、性能成本、可观测性、易用性控制、标准化产品化、最终达到超越与自我实现。 阅读全文

73 - 分布式数据库是不是伪需求？

随着硬件技术进步，单机数据库的容量和性能已达到前所未有的高度。分布式 TP 数据库在这种变革面前显得极为无力，和"数据中台"一样穿着皇帝的新衣，处于自欺欺人的状态里。 阅读全文

74 - 微服务是不是个蠢主意？

原文链接：https://world.hey.com/dhh/microservices-are-a-bad-idea-7a8dbddc

连 SOA 典范亚马逊自己都觉得微服务和 Serverless 拉胯了。Prime Video 团队放弃微服务改用单体架构，运营成本节省了惊人的90%。微服务就像塞壬歌声一样诱惑你为系统添加毫无必要的复杂度。 阅读全文

75 - 是时候和 GPL 说再见了

原文链接：https://martin.kleppmann.com/2021/04/14/goodbye-gpl.html

DDIA 作者 Martin Kleppmann 认为应远离 GPL 及相关许可证，因为它们未能实现其目的，造成的麻烦比产生的价值更大。在2020年代，计算自由的敌人是云软件，本文倡导本地优先软件的概念。 阅读全文

76 - 容器化数据库是个好主意吗？

生产环境的数据库是否应当放入容器中，仍然是一个充满争议的问题。站在开发者角度我喜欢 Docker，但站在 DBA 立场上，我认为就目前而言，将生产环境数据库放入 Docker/K8S 中仍然是一个馊主意。 阅读全文

77 - 理解时间：闰年闰秒，时间与时区

四年一遇的闰年2月29日，总有土鳖软件出现大翻车。对时间的正确理解，对正确处理工作生活中的时间问题很有帮助。本文聊一聊闰年、闰秒、时间与时区的原理，以及在数据库与编程语言中的注意事项。 阅读全文

78 - 理解字符编码原理

如果不了解字符编码的基本原理，即使只是简单常规的字符串比较、排序、随机访问操作，都可能会一不小心栽进大坑中。本文详细解析 ASCII、Unicode、UTF-8 等编码原理，希望能讲清楚这个问题。 阅读全文

79 - 并发异常那些事

并发程序很难写对，更难写好。很多程序员只是把问题丢给数据库，但即使最强大的 ACID 数据库也会使用弱隔离级别。本文阐述 SQL92 标准定义的隔离级别及其缺陷，以及现代模型中的隔离级别定义。 阅读全文

80 - 区块链与分布式数据库

区块链的技术本质、提供的功能及演化方向就是分布式数据库。确切地讲，是拜占庭容错（抗恶意节点攻击）的分布式（无领导者复制）数据库。智能合约本质上就是这个分布式数据库上的存储过程。 阅读全文

81 - 一致性：过载的术语

一致性这个词重载得很厉害，在不同语境中代表着不同的东西。ACID 里的 C 指事务一致性，CAP 里的 C 指线性一致性，此外还有"一致性哈希"、“最终一致性"等不同涵义。本文梳理这些概念的区别。 阅读全文

82 - 为什么要学习数据库原理

只会写代码的是码农，学好数据库基本能混口饭吃。然而对优秀的工程师来说，只会用数据库是远远不够的。绝大多数应用都是数据密集型应用，数据库提供了对应用通用存储需求的高级抽象。 阅读全文