技术文章Andy Pavlo Database Blog
Andy Pavlo 撰写的 2025 年数据库年度回顾，以 PostgreSQL 的持续主导为主线，梳理全年行业格局与技术动向。文中记录了 Databricks 以 10 亿美元收购 Neon、Snowflake 收购 CrunchyData、微软推出 HorizonDB 等交易，并分析 Multigres、Neki、PgDog 三个分布式分片项目对 PostgreSQL 水平扩展能力的意义。作者还评述各 DBMS 竞相推出 MCP 服务器接入 LLM/Agent 及其权限与防护风险、MongoDB 起诉 FerretDB 的专利商标纠纷，以及 FastLanes、F3、Vortex、AnyBlox 等新列式文件格式对 Parquet 的挑战。文章同时汇总全年收购、合并与融资清单，并附作者点评与历史脉络考证。其内容以行业观察与主观判断为主，并非技术教程，趋势预测带有个人立场，读者需结合原始资料核实。
推荐收录：作者为 CMU 数据库教授，该系列已成为数据库领域公认的年度权威综述，文中对 PostgreSQL 生态并购、MCP 接入 LLM 的安全隐患、列式文件格式竞争给出了有据可查的事实与判断。适合数据库工程师、架构师与研究者快速建立年度技术脉络，可作为长期索引；但内容偏向行业观察与个人观点，具体机制仍需回到原始资料与论文核实。
科研议题Andy Pavlo Database Blog
Andy Pavlo 对 2023 年数据库领域的年度回顾，从技术、产品与产业三条线梳理全年关键事件。文章解释向量数据库因 LLM 爆发而走红的技术原理（embedding 与近似最近邻检索），并对比 JSON 类型的普及历史，指出其工程门槛较低、护城河可能不足。随后分析 SQL:2023 新增的 SQL/PGQ 属性图查询与 SQL/MDA 多维数组，讨论图查询对最坏情况最优连接和因子化等优化技术的依赖。作者还复盘 MariaDB 公司 IPO 后的财务危机、FAA NOTAM 遗留系统数据库文件损坏导致全美航班停飞，以及数据库领域融资与并购。文章观点鲜明但带有个人调侃色彩，具体厂商数据和判断需结合原文与后续事实核验。
推荐收录：作者是数据库领域知名学者，文章不仅回顾年度事件，还给出向量数据库、SQL:2023 新特性及查询优化挑战的技术判断，并辅以 MariaDB、FAA NOTAM 等真实教训。适合数据库工程师、研究者和架构师把握技术脉络与选型风险，但需注意其观点性和年度快照属性。
技术文章Andy Pavlo Database Blog
文章围绕 PostgreSQL 的 MVCC 实现，系统讨论版本复制、表膨胀、二级索引维护和 vacuum 管理四类问题及优化手段。作者指出，更新复制整行、死元组与活元组同页存储、索引写放大以及 autovacuum 配置复杂，会带来存储浪费、I/O 升高和查询变慢，其中版本复制不重写内核难以根治。优化上建议用 pgstattuple 或估算脚本监控膨胀，用 pg_repack 在线回收空间，通过 pg_stat_all_indexes 清理重复和未使用索引；vacuum 方面则需表级调小 autovacuum_vacuum_scale_factor、监控长事务与进度，并调优 work_mem、cost_limit、cost_delay。文章结论是 PostgreSQL 虽有问题仍值得坚持，但优化高度依赖人工判断，pg_repack 和杀事务等操作需在低峰并评估业务风险。
推荐收录，因为文章由数据库研究者撰写，针对 PostgreSQL MVCC 的版本复制、膨胀、索引维护和 vacuum 四个具体问题，给出了 pgstattuple、pg_repack、pg_stat_* 视图与 autovacuum 参数的诊断/调优路径，技术证据明确。适合 DBA、后端工程师和数据库系统研究者用于生产运维、容量规划和 MVCC 权衡；但部分操作需低峰执行并评估杀事务风险，且文中含 OtterTune 产品推广。
技术文章Andy Pavlo Database Blog
文章由 Andy Pavlo 与 Bohan Zhang 合作，系统批评 PostgreSQL 的 MVCC 实现。核心指出 PostgreSQL 采用 append-only 版本存储、O2N 版本链和每版本索引项，导致版本复制、表膨胀、二级索引写放大和 autovacuum 管理困难四大问题。作者对比 MySQL、Oracle 使用 delta 存储与逻辑指针的做法，说明 PostgreSQL 设计是 1980 年代遗留方案，不推荐新 DBMS 效仿。文中引用 CMU 研究与 OtterTune 客户监控数据，包括 Uber 从 Postgres 迁移 MySQL 的案例，但结论更偏向写密集负载，并非完整中立的 benchmark。
推荐收录：文章以存储布局、版本链、索引维护和 autovacuum 行为等具体机制，直接说明 PostgreSQL append-only MVCC 的性能代价，并给出与 MySQL/Oracle 的对照证据。适合数据库内核、DBA、后端架构师和云数据库选型者阅读，可迁移到 MVCC 设计、写放大评估、索引优化和 vacuum 调优场景；需注意其结论偏向写密集工作负载。
技术文章Andy Pavlo Database Blog
本文是 Andy Pavlo 对 2022 年数据库领域的年度回顾，按融资、区块链数据库、新系统、人物纪念等主题梳理行业动态。作者指出数据库创业融资在下半年明显转冷，并以架构分析讨论 Google AlloyDB、Snowflake Unistore、MySQL Heatwave、Meta Velox、InfluxDB IOx 等新系统；他认为 Velox、DataFusion 等可扩展执行引擎会推动 OLAP 查询执行组件商品化，未来差异化将转向 UI/UX 与查询优化。文章还强烈批评区块链数据库在加密货币之外缺乏实际用例，并纪念 Martin Kersten 对 MonetDB、列存与向量化执行的贡献。内容带主观立场和大量个人评论，不是严格技术论文或实验报告，但可作为观察 2022 年数据库生态的参考。
推荐收录，因为文章由数据库领域知名研究者撰写，直接记录了 2022 年数据库融资、产品发布与系统架构变化，并对 AlloyDB、Velox 等给出可讨论的架构判断。适合数据库研究者、系统架构师和基础设施从业者了解行业趋势与技术脉络。需注意其观点主观、夹杂段子和政治玩笑，且缺少实验数据，不能替代深度技术论文。
技术文章Andy Pavlo Database Blog
文章借用 Notorious B.I.G. 的《Ten Crack Commandments》，提出十条数据库运维与管理戒律。内容涵盖：不向厂商暴露预算、最小权限、监控数据不存回同一 DBMS、应用与 DBMS 分离、避免无休止调参、限制单实例多租户、及时执行维护任务、不要为未到来流量过度配置等。作者结合 Postgres/MySQL 的行级安全、MVCC、自动 vacuum，以及 AWS RDS 的预留实例和维护窗口等具体机制说明取舍。文章带有 OtterTune 产品推广色彩，部分云产品价格与功能具有 2022 年时效性，但多数原则对数据库性能、可靠性和成本治理仍有长期参考价值。
推荐收录。文章虽以歌曲类比并含 OtterTune 推广，但十条规则均给出可验证的数据库运维依据，如行级安全、MVCC、自动 vacuum、多租户资源竞争和云实例过度配置的代价。适合 DBA、后端/SRE 与使用云数据库的工程团队作为检查清单，其中最小权限、监控分离、预留实例和维护窗口等经验可迁移到生产系统；需注意云产品细节和厂商立场带来的时效与偏向。
工程实践Andy Pavlo Database Blog
文章由 Andy Pavlo 撰写、原载 OtterTune，讨论 AWS RDS 用户常见的三类数据库过度支出：盲目选择过大实例、沿用默认配置、以及过度购买 Provisioned IOPS。作者用 PostgreSQL RDS 和 TPC-C 基准做对比实验，显示垂直扩容超过 db.m5.8xlarge 后吞吐不再提升，优化配置后较小实例可达到大实例默认配置的吞吐且年成本减半，而写密集负载下 PIOPs 超过 10k 后收益递减。结论是先做数据库调优和容量规划，再决定规格与云资源，可避免为未使用能力付费。边界是实验基于特定 AWS RDS 版本、实例族和 2021 年定价，且文章带有 OtterTune 产品推广倾向。
推荐作为工程案例收录：文中用 TPC-C 对比默认配置与调优配置、实例规格和 PIOPs 曲线，给出“先调优再扩容”的可验证证据。适合 DBA、后端与云成本优化读者，用于评估 RDS 规格、配置和 I/O 预算。需注意作者推广 OtterTune，且 AWS 定价与实例型号已变化，应结合当前环境复测。
个人心得Andy Pavlo Database Blog
文章由 Andy Pavlo 回顾为 DBMS 命名的困难，结合 H-Store、Peloton 及 CMU 自研数据库的亲身经历，分析数据库命名中常见的后缀模式、相似名称冲突和改名案例。作者统计 dbdb.io 中 700 多个数据库的命名，指出 DB、SQL、Base 等后缀高度同质，并讨论搜索引擎可见性、商标争议和开发者品牌认同。随后提出“Pavlo Database Naming Method”：由两个不相关单音节词组合成双音节、独特且易拼写的名字，以 Postgres 和 Clickhouse 为最佳范例，并以 BusTub 作为实践案例。该方法的适用边界是学术项目和早期项目，商业系统可能需要直白名称；作者也承认颜色词、已有含义词等例外，且结论带有个人偏好和幽默色彩。
推荐收录。文章虽以幽默随笔形式写成，但提供了数据库命名这一常被忽视的工程文化议题的系统观察：后缀统计、同名冲突、改名案例和可操作的命名方法，来自长期数据库研究者的亲身经验。对设计开源数据库、产品或学术系统命名的人有直接参考价值，也可迁移到其他开发者工具的品牌与可发现性决策；不过其命名方法偏学术和个人审美，商业采用需结合商标与市场约束。