PostgreSQL

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？ PostgreSQL、Redis、DuckDB——三者都管自己叫「数据库」，但架构几乎没有一处相同。本文从一个问题出发：为什么「存数据」这一件事，需要三种截然不同的答案？ 先说个真实感受：新人问我「该用什么数据库」时，我最怕听到的是「就……存点数据」。因为「存数据」这个需求背后，至少藏着三个互相矛盾的目标：要快（延迟）、要对（一致性）、要能算（分析吞吐）。这三个目标在物理层面就是打架的，所以业界长出了三种完全不同形态的数据库，各自押注一个目标。 这篇拿 PostgreSQL（75K+ Star 里的常青树）、Redis（75K Star）、DuckDB（40K Star）当样本——它们恰好是三条路线的教科书级代表。 三种数据库，三种「世界观」 PostgreSQL Redis DuckDB 一句话定位 数据的基础设施 远程数据结构接口 SQLite for Analytics 押注的目标 正确性 > 性能 延迟 > 一切 分析吞吐 + 零部署 数据在哪 磁盘（缓冲进内存） 内存 就在文件里（CSV/Parquet/S3） 并发模型 多进程、MVCC 多版本 单线程事件循环 单写者、Morsel 并行读 典型场景 金融、ERP、订单 缓存、会话、排行榜、限流 数据科学家本地跑 SQL 分析 注意：这三行的每一列差异都不是「实现细节」，全是世界观分歧。往下看。 PostgreSQL：把「正确」放在所有选项的前面 PostgreSQL 从 1986 年 Berkeley 的学术项目走到今天，38 年没死，靠的不是快——它从来不追求最快。它的护城河是正确性和可信度的复利。 几个能看出价值观的设计： 1. Process-per-connection：每个连接一个独立进程。 MySQL（InnoDB）用线程池，PG 用进程。进程更重、启动更慢，但一个连接崩了不会带走别人——内存隔离是操作系统保证的，不是代码纪律保证的。这是「可靠性高于便利」的字面体现。 2. MVCC 的代价是 VACUUM。 读写互不阻塞的代价是旧版本数据堆在表里，得靠 VACUUM 回收。很多人骂 VACUUM 烦，但这笔交易是明码标价的：读永远不阻塞写、写永远不阻塞读，换来的运维成本。对比 MySQL undo log 的回收方式，各有取舍，但 PG 把旧版本直接放主表的设计，让「时间旅行」「闪回查询」这类能力成为可能。 ...

一次真实的升级记录。 从 Ubuntu 默认 Cluster 管理模式，迁移到 PostgreSQL 官方推荐目录结构。 全程使用 pg_upgrade，保留所有数据库，最终实现： PostgreSQL 18 官方数据目录 systemd 管理 MacBook 远程访问 完整踩坑记录 一、为什么升级？ 原环境： 项目 版本 Ubuntu 24.04 PostgreSQL 16.14 数据目录 /srv/data/db/postgres/16/main 希望升级到： PostgreSQL 18.4 PostgreSQL 18 vs 16 关键改进 特性 PostgreSQL 16 PostgreSQL 18 增量备份 ❌ 仅全量 ✅ pg_basebackup 支持增量，备份时间减少 50%+ 逻辑复制 基础支持 ✅ 支持序列和大对象复制 并行查询 有限并行 ✅ 更多场景支持并行（VACUUM、CREATE INDEX） JSON 处理 JSONB 基础 ✅ JSON_TABLE 增强，复杂查询更高效 SSD 优化 无特殊处理 ✅ 强制 I/O 调度优化（见下文） 连接池 需外部工具 ✅ 内置连接池改进 SSD 专项优化（重要） PostgreSQL 18 对 NVMe/SSD 做了底层优化，这是升级的核心理由： ...

一台 16GB 内存的家用服务器，PostgreSQL 跑起来总觉得慢，改配置又怕改坏——这篇文章用真实的配置文件逐项拆解，告诉你哪些参数值得动，动多少合适。 开场：一次"改坏"的调优经历 上周帮朋友调一台家用服务器上的 PostgreSQL，他信誓旦旦说"我照着网上的教程改了 shared_buffers 到 8GB，结果数据库直接起不来了"。我一看配置——16GB 的机器，shared_buffers 给了 8GB，再加上操作系统缓存、其他服务，内存直接 OOM。 这种故事在家庭服务器圈子里太常见了。PostgreSQL 的 postgresql.conf 有几百个参数，但真正需要动的也就十来个。今天我们用一台真实的家用机器配置，逐项拆解。 硬件家底：你的机器够干多大的活 先看看今天的实验对象： 项目 配置 CPU 12th Gen Intel i5-1240P（12核16线程） 内存 16GB 磁盘 SSD 系统 Ubuntu 24.04 LTS PG 版本 PostgreSQL 16 16GB 内存、SSD、12 代酷睿——这是典型的家用 NAS 或者小型工作站配置。够用，但没有太多余量可以挥霍。 第一梯队：内存分配三兄弟 PostgreSQL 的性能调优，80% 就是调内存分配。搞明白三个参数，基本就入门了。 shared_buffers — 数据库的"工作台" shared_buffers = 2GB 这是 PostgreSQL 自己用来缓存数据页的内存。你可以把它想象成厨师的工作台——台面越大，能同时摊开的食材越多，不用反复跑冰箱拿东西。 经验法则：物理内存的 25%。16GB 的机器给 2GB 是合理的。给太大（比如 8GB），操作系统缓存会被挤掉，反而变慢；给太小，频繁读磁盘，性能拉胯。 验证方法： SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size, pg_size_pretty(pg_total_relation_size('projects')) AS table_size; 如果你的数据库总量小于 shared_buffers，那说明数据全在缓存里，调大没意义。 ...

上一篇聊了家用 PostgreSQL 的配置调优，这篇来点硬的——100 万条数据，PostgreSQL 的查询计划选择会发生什么变化？索引策略又该怎么调？ 开场：当 30 条变成 100 万条 上篇博客里，我们的 projects 表只有 30 条数据。COUNT 一下 0.97ms，排序一下 0.54ms，快得飞起。但你心里清楚——30 条数据，任何数据库都不会慢。 真正的考验是：数据量上来之后，你的索引还管用吗？优化器还会乖乖走 Index Scan 吗？ 今天我们用 100 万条真实数据，把 PostgreSQL 的查询计划拆个底朝天。 实验环境 项目 配置 CPU 12th Gen Intel i5-1240P（12核16线程） 内存 16GB 磁盘 SSD PG 版本 PostgreSQL 16 数据量 1,000,000 行 数据大小 174 MB 索引大小 74 MB 总大小 248 MB 100 万行，248MB——不大不小，刚好是很多真实项目的规模。 插入性能：100 万条要多久 1,000,000 条批量插入: 12.7 秒 平均每秒约 7.8 万条。用的是逐批 10000 条的 INSERT ... VALUES 拼接方式，没有用 COPY。如果用 COPY FROM STDIN，速度还能再快 2-3 倍。 ...