本系列第一期回顾：SQL Server 2025 通过原生向量数据类型、DiskANN 索引、T-SQL AI 函数和 ONNX 模型本地托管，将 AI 深度集成至数据库内核，实现了从“存储数据”到“理解数据”的范式革命。本期作为系列第二期，我们将目光投向企业级生产环境的另一核心命题——高可用性、混合架构与数据迁移，详细解读 SQL Server 2025 在这些关键领域带来的实质性革新。 一、高可用性与灾难恢复：不止于“可用”，更追求“智慧” 对于承载核心业务的生产系统而言，高可用性（HA）与灾难恢复（DR）是生命线。SQL Server 2025 在这一领域的进化，核心可概括为 “降低复杂度、缩短停机时间、提升自动化水平”。 1.1 Always On 可用性组（AG）：围绕 DBA 痛点的精准改良 Always On 可用性组是 SQL Server 高可用体系的基石，2025 版本并未对架构进行颠覆，而是精准回应了 DBA 在日常运维中长期积累的痛点。次要副本现支持完整备份和差异备份，而不仅限于仅复制备份（copy_only），这意味着企业可以将备份任务从主副本安全地卸载到辅助副本，从而释放主副本的资源压力，同时仍能维持完整备份链的连续性。 可读辅助副本的生产力也得到实质性提升——查询存储（Query Store）数据现已同步到可读辅助副本，DBA 在任何副本上都能获得统一的性能视图，无需跨节点切换即可完成性能诊断。在配置与管理体验上，更完善的监控工具、更易发现的设置选项以及更友好的用户界面，都降低了 AG 的日常运维门槛。 1.2 包含的可用性组（CAG）：元数据自治的高可用单元 如果说传统 AG 简化的是数据库层面的高可用，那么 Contained Availability Group（CAG）则将这一简化扩展到了实例层面。CAG 的设计目标是通过将系统数据库（master、msdb）封装在可用性组内部，实现高可用和灾难恢复的全方位简化。这意味着登录名、作业、凭据以及其他元数据都会在各副本之间自动复制，彻底告别手动同步的运维负担。 从 SQL Server 2025 CU1 开始，CAG 的能力进一步提升：管理员可直接通过 CAG 监听器创建或还原数据库，而无需连接到物理 SQL Server 实例。这一能力通过启用会话上下文键或调用自动化存储过程 sp_sysutility_cag_create_db 即可实现，对限制直接访问 SQL 实例的生产环境尤为实用。 CAG 的核心价值在于：每个 CAG 都拥有独立的 master 和 msdb 副本，使其成为不依赖于物理 SQL 实例的自包含高可用单元。当 AG 发生故障转移时，所有相关元数据都会随之迁移，确保应用无需人工干预即可继续运行；同时，由于操作范围可限定在 AG 上下文内，系统的安全暴露面也得到了有效控制。 1.3 分布式可用性组（DAG）与故障转移优化 SQL Server 2025 对分布式可用性组（DAG）的支持进一步成熟，为跨地域的容灾部署提供了更稳健的基础。在故障转移体验方面，SQL Server 2025 包含了故障恢复过程的性能改进，配合增强的监控能力，显著减少了故障转移期间的停机时间。配合分布式网络名称（DNN）侦听器的使用，故障转移速度进一步提升：由于无需等待网络负载均衡器检测失败事件和变更路由，使用 DNN 时的故障转移时间显著缩短。 1.4 备份与恢复的现代化演进 SQL Server 2025 在备份领域引入了多项重要革新：新增 ZSTD 压缩算法作为备份压缩选项，相比传统压缩算法提供更高的压缩比和更快的压缩速度；S3 兼容对象存储备份全面进入生产可用状态，企业可以直接将数据库备份到 MinIO、Dell ECS、Cloudian 等各类 S3 兼容存储，为备份策略提供了前所未有的灵活性；Azure Blob 不可变存储支持在指定保留期内防止备份被篡改或删除，对金融、医疗等强合规行业至关重要。此外，加速数据库恢复（ADR） 机制在 SQL Server 2025 中得到进一步增强，大幅缩短了崩溃恢复和事务回滚的时间，为高可用性提供了底层支撑。 二、混合架构与云集成：跨越边界的统一数据平台 现代企业的数据基础设施几乎必然跨越本地、云端和边缘。SQL Server 2025 在这一领域的核心命题是：如何让数据在不同环境之间自由流动，同时保持管理的统一性与安全性？ 2.1 Fabric 镜像：无 ETL 的准实时数据同步 Fabric 镜像是 SQL Server 2025 在混合架构领域最具突破性的功能。它允许将本地 SQL Server 数据库近乎实时地镜像到 Microsoft Fabric 的 OneLake 中，让运营数据立即可供 Power BI、Synapse 等分析工具消费，彻底绕开了传统 ETL 管道的复杂性。 在 SQL Server 2025 中，Fabric 镜像的核心机制从传统的变更数据捕获（CDC）升级为全新的 Change Feed。相比 CDC 需要在源数据库维护变更表、通过两步过程（日志 → 变更表 → OneLake）完成数据同步，Change Feed 直接高频扫描事务日志并将已提交变更发布到 OneLake，消除了中间的写入步骤。 这一架构升级带来了多维度的收益：降低性能开销——没有变更表需要维护，没有 SQL Agent 作业需要管理，对于繁忙的 OLTP 系统是实质性的改善；更强的 DDL 适应性——检测到表结构变更时自动触发完整重新快照并重新播种，实现了自愈能力，避免镜像因一次部署而中断整个周末；更简洁的权限模型——不再要求 sysadmin 角色进行配置，满足了安全敏感型组织的合规要求。 需要注意的是，Fabric 镜像要求 SQL Server 实例启用 Azure Arc，通过本地数据网关配置安全连接。当前版本在架构演进、大表处理和初始化行为方面仍存在一定限制，生产环境部署前需进行充分评估。 2.2 Azure Arc：混合环境的统一管理平面 如果说 Fabric 镜像解决的是数据流动的问题，那么 Azure Arc 解决的则是混合环境的管理难题。通过 Azure Arc，企业可以将本地 SQL Server 实例扩展到 Azure 管理平面，获得统一的治理、监控和安全体验，无论 SQL Server 运行在 Windows、Linux 还是 Kubernetes 集群上。 SQL Server […]

SQL Server 2025 新技术系列介绍（第一期）—— AI 革命：当数据库真正“学会思考” 引言 如果说 SQL Server 2022 是微软向云端的优雅转身，那么 SQL Server 2025 则是一场彻底的自我重塑。2025 年 11 月 19 日，在微软 Ignite 2025 大会上，SQL Server 2025 正式结束预览测试并投入生产环境。而就在几天前（2026 年 4 月 23 日），CU3 累积更新也已正式发布，标志着这一版本正以稳健的步伐走进企业的核心系统。 本期作为系列的开篇，我们将聚焦 SQL Server 2025 最具颠覆性的变革——AI 深度集成，同时完整呈现其在性能、安全、混合部署等维度的全面进化。这不是一次常规的版本迭代，而是一场将数据库从“存储系统”转变为“智能平台”的范式革命。 一、从“存数据”到“理解数据”：AI 的深度内嵌 如果说过去十年数据库的核心命题是“更快、更稳、更安全”，那么 SQL Server 2025 给出了新的答案：更聪明。 SQL Server 2025 首次将 AI 能力深度整合至数据库引擎底层，而非简单地在数据库之上叠加 AI 工具层。这意味着开发者可以直接在数据库内部完成从数据存储到语义理解的全流程，无需将数据搬运到外部的 AI 服务或 Python 环境。微软将这一架构理念概括为 “AI Where Your Data Lives” ——让智能发生在数据所在之处，而非迁移数据去迁就智能。 为什么这很重要？ 传统方案中，若要实现语义搜索，你需要将数据导出、调用外部 embedding 模型、建立向量数据库、再处理查询……这不仅带来了数据传输的安全风险，也大幅增加了系统的复杂度和延迟。SQL Server 2025 将这些全部内置于引擎内部，用最熟悉的 T-SQL 即可完成端到端的 AI 应用开发。 1.1 原生向量数据类型：为语义搜索筑基 向量数据的存储与检索是 AI 应用的核心基础设施。SQL Server 2025 新增了原生的 VECTOR 数据类型，开发者可以直接在数据表中定义向量列，并通过 T-SQL 创建和管理向量索引。 向量是什么？简单来说，AI 模型会将文本、图像等内容转化为一串高维数字数组（即向量）。两个向量的距离越近，代表原始内容的语义越相似。借助这一机制，数据库能够理解“苹果”与“水果”“iPhone”之间的关联，而不仅仅是关键词匹配。 RC1 版本进一步引入了 FP16（半精度浮点数）支持，允许以 2 字节存储向量中的每个维度，相比传统的 4 字节（FP32）可节省一半的存储空间。对于动辄数百甚至数千维的 AI 向量，这一优化带来的存储和内存收益极为可观。向量数据类型支持最多 3996 个维度，足以覆盖绝大多数主流 embedding 模型的需求。 1.2 DiskANN 索引技术：让向量搜索快如闪电 仅有向量存储还不够，如何高效检索才是真正的挑战。SQL Server 2025 集成了微软研究院研发的 DiskANN 技术，这是一种专为高维向量设计的近似最近邻（ANN）搜索算法，能够在磁盘上构建高效的向量索引，相比传统的内存方案大幅降低资源消耗。 在 RC1 中，DiskANN 获得了显著增强：索引构建速度大幅提升（更好地利用所有 CPU 核心），跨所有处理器的扩展性显著改善，从而在面对大规模数据集和高吞吐量负载时能够保持一致的性能表现。 值得特别关注的是，向量索引的创建不再对表加 SCH-M 锁，允许在索引构建过程中保持完整的读访问能力——这对生产环境的意义不言而喻。 1.3 混合搜索：向量 + 全文 + 过滤的“组合拳” 现实中的搜索需求往往是多维度的：既要有语义相关性，也要满足特定的过滤条件（如价格区间、时间范围）。SQL Server 2025 支持将向量搜索与传统的全文检索和结构化过滤逻辑相结合，提供强大的混合搜索能力，让开发者可以在同一个查询中融合多种搜索范式。 1.4 T-SQL AI 函数：用熟悉的 SQL 驾驭大模型 SQL Server 2025 在 T-SQL 层面新增了一系列 AI 函数，让开发者用最熟悉的语法调用大模型能力： 函数 功能说明 AI_GENERATE_EMBEDDINGS 生成文本的向量嵌入 AI_GENERATE_CHUNKS 将长文本智能分块，便于 RAG 处理 VECTOR_SEARCH 执行向量相似性搜索 这些函数支持与 Azure OpenAI、OpenAI、Ollama 等主流 AI 服务无缝集成，开发者可以在不同模型之间随意切换而无需修改代码——今天用 OpenAI，明天换 Ollama，就像换个电源适配器一样简单。 1.5 ONNX 模型本地托管：数据不出门的 AI 推理 对于一些对数据隐私有严格要求的场景，将数据发送到云端 API 可能并不合适。SQL Server 2025 通过 CREATE EXTERNAL MODEL 语句，支持在数据库文件系统中直接托管本地的 ONNX 模型，实现完全离线的 AI 推理能力。这一功能在预览阶段可通过 PREVIEW_FEATURES 配置启用。 1.6 RAG 应用支持：构建企业级智能问答系统 RAG（检索增强生成）是当下企业构建 AI 应用的主流架构——先通过向量搜索从企业知识库中检索相关内容，再将这些内容作为上下文提交给大语言模型生成答案。SQL Server 2025 为 RAG 提供了完整的基础设施支持：向量嵌入生成、文本分块、DiskANN 索引等核心构建块一应俱全，并能与 LangChain、Semantic Kernel 及 Entity Framework […]

第五期：PostgreSQL扩展开发实战——用Rust构建自己的PG扩展 从零到一，深度掌握PostgreSQL扩展开发的完整生命周期 在前四期的专题中，我们看到了PostgreSQL生态的蓬勃力量：从PG 18/19的内核新特性，到向量检索的飞速演进，再到云原生分布式架构的深刻变革。而这些能力的基石，正是PostgreSQL引以为傲的扩展性。 PostgreSQL之所以能够从一款关系型数据库成长为综合性数据平台，其扩展架构是根本原因。PostGIS、TimescaleDB、pgvector、Citus——几乎所有改变游戏规则的能力，都始于一个扩展。而2026年，随着pgrx框架的全面成熟，用Rust开发PG扩展正在从“前沿探索”走向“生产标准”。 本期将带读者从零开始，掌握用Rust构建PostgreSQL扩展的完整流程。 一、为什么PostgreSQL需要扩展？扩展生态全景 PostgreSQL的扩展架构是其区别于大多数数据库的关键设计——数据库核心保持精简，所有附加能力以扩展形式提供。 扩展与普通SQL对象的本质区别在于：扩展是一组可安装、可版本化、可卸载的数据库对象的打包单元。一个扩展至少包含一个控制文件（.control）定义元数据（名称、版本、依赖等），以及一个SQL脚本文件用于创建扩展内的数据库对象。当扩展包含C语言实现的高性能函数或自定义数据类型时，还需要编译为共享库（.so）。 2026年的PG扩展生态已高度繁荣。根据PGXN（PostgreSQL Extension Network）的统计数据，已有数百个扩展覆盖了从地理空间（PostGIS）、时序数据（TimescaleDB）、向量检索（pgvector）、全文搜索（ParadeDB）到分布式分片（Citus）的几乎所有数据场景。更值得关注的是，2026年1月，PostgreSQL官方宣布了pgpm项目，旨在为纯SQL模块引入包管理机制，将模块化能力从系统级扩展下沉到应用层数据库逻辑。 与此同时，Kubernetes生态也在推动扩展部署模式的变革。PostgreSQL 18引入的extension_control_path配置项，允许从非系统目录加载扩展控制文件，彻底解耦了扩展与数据库核心镜像的生命周期。在CloudNativePG框架下，扩展可以打包为不到10MB的scratch镜像独立于数据库镜像发布，CI/CD流程也随之解耦。 二、扩展开发的两种路径：C vs. Rust 在pgrx出现之前，编写一个包含自定义函数或数据类型的PG扩展，意味着要在C语言中完成全部实现——手动处理内存上下文、手动管理引用计数、手动编写SQL注册脚本。一个指针错误就可能导致整个数据库进程崩溃。 pgrx的出现彻底改变了这一局面。pgrx是一个用Rust语言构建PostgreSQL扩展的完整框架，由两个核心组件构成：pgrx库提供Rust与PostgreSQL交互的基础设施；cargo-pgrx子命令管理从初始化到打包的整个开发流程。 两种路径的选择本质上取决于开发者的优先级： 选择C扩展的场景：深度集成PG内核、直接操作核心数据结构、最大化性能极致，且团队具备成熟的C开发能力； 选择Rust扩展的场景：绝大多数其他情况——尤其是涉及复杂业务逻辑、需要长期维护、或希望利用Rust丰富crates.io生态的扩展项目。 💡 深度洞察：pgrx的价值不仅在于“用Rust替代C”。它将Rust的现代开发体验——包管理、单元测试、类型系统、错误处理——完整地带入了PG扩展开发流程。对于希望将数据库扩展作为产品核心的企业而言，这种开发效率的提升具有战略意义。 三、pgrx核心特性全景 3.1 完全托管的开发环境 cargo-pgrx是整个工具链的核心入口。cargo pgrx init命令自动下载并编译PostgreSQL 13到18的所有版本，为每个版本配置调试符号和断言。开发过程中最常用的命令是cargo pgrx run——一条命令完成编译、安装到指定PG实例、启动服务、打开psql终端四个步骤。 跨版本测试同样简洁：cargo pgrx test all对所有支持版本运行测试套件，确保扩展的兼容性。 3.2 自动SQL生成 这是pgrx最具生产力的特性之一。开发者只需在Rust中实现功能，pgrx自动生成对应的CREATE FUNCTION、CREATE TYPE等SQL定义。这消除了传统C扩展中手动维护SQL注册脚本的繁琐和易错问题。 3.3 安全第一的内存管理 pgrx将Rust的所有权和生命周期规则带入PG扩展开发。它严格遵循Rust的drop语义管理内存，并通过#[pg_guard]过程宏确保panic时被正确捕获为PostgreSQL ERROR而非进程崩溃。 3.4 完整的功能覆盖 pgrx支持定义SQL可调用的函数、自定义聚合、用户定义类型、枚举、触发器、后台工作者、索引访问方法，甚至是新的表访问方法。这种覆盖广度意味着几乎任何PG扩展都可以用Rust重写。 四、实战：从零构建一个PG扩展 让我们通过一个完整的示例项目——一个用于文本情感分析的扩展——串联pgrx的核心开发流程。 4.1 环境搭建 首先安装cargo-pgrx并初始化开发环境： # 安装cargo-pgrx工具链 cargo install --locked cargo-pgrx # 初始化开发环境（自动下载并编译PG 13-18） cargo pgrx init # 创建新扩展项目 cargo pgrx new pg_sentiment cd pg_sentiment cargo pgrx new生成的目录结构包含了扩展开发所需的核心文件：Cargo.toml（依赖管理）、src/lib.rs（扩展代码）、以及自动生成的.control和SQL文件模板。 4.2 定义扩展的核心函数 在src/lib.rs中编写扩展逻辑。pgrx使用#[pg_extern]宏将Rust函数暴露为PostgreSQL SQL函数： use pgrx::prelude::*; pgrx::pg_module_magic!(); // 简单的文本情感分析函数 #[pg_extern] fn analyze_sentiment(text: &str) -> String { let positive_words = ["good", "great", "excellent", "amazing", "love"]; let negative_words = ["bad", "terrible", "awful", "hate", "poor"]; let lower = text.to_lowercase(); let pos_count = positive_words.iter() .filter(|&w| lower.contains(w)).count(); let neg_count = negative_words.iter() .filter(|&w| lower.contains(w)).count(); if pos_count > neg_count { "positive".to_string() } else if neg_count > pos_count { "negative".to_string() } else { "neutral".to_string() } } // 返回Result的错误处理示例 #[pg_extern] fn safe_divide(a: f64, b: f64) -> Result<f64, &'static str> { if b == 0.0 { Err("division by zero") } else { Ok(a / b) } } 关键点：#[pg_extern]宏自动处理输入参数的Rust类型到PostgreSQL Datum的转换，以及返回值的反向转换。如果函数返回Result，Err变体自动转换为PostgreSQL ERROR。 4.3 定义自定义类型 pgrx支持将Rust结构体映射为PostgreSQL自定义类型： use pgrx::datum::JsonB; use serde::{Serialize, Deserialize}; #[derive(PostgresType, Serialize, Deserialize)] pub struct SentimentResult { pub label: String, pub confidence: f64, pub positive_score: […]

第四期：云原生PostgreSQL的分布式架构演进 从分片到存算分离，2026年PostgreSQL如何征服大规模数据挑战 在前三期技术专题的铺垫下，我们已经看到PostgreSQL 18/19的内核能力持续增强，向量检索与图查询等AI生态能力快速融合。而真正驱动PostgreSQL完成“单机数据库→综合性数据平台”这一角色跃迁的底层力量，源自云原生架构的深刻变革。 2026年的PostgreSQL分布式生态，正在经历一场从“分片扩展”到“存算分离”的范式迁移。当Citus、Apache Cloudberry等社区主力持续进化的同时，Google Cloud推动的逻辑复制向主动-主动架构演进、阿里云Serverless Pro模式对存算分离的工程化落地，以及EDB、Aurora、YugabyteDB等商业与开源力量的齐头并进，共同勾勒出一幅云原生时代的分布式PostgreSQL全景图。 一、Citus 14.0：将PG 18的力量带到分布式集群 作为PostgreSQL生态中应用最广泛的分片扩展，Citus在2026年2月迎来了14.0版本，其核心使命是完整适配PostgreSQL 18。 1.1 PG 18能力在分布式集群中的“免费午餐” Citus的实现方式决定了它作为PostgreSQL扩展的本质：一个Citus集群本质上是多个独立PostgreSQL实例（协调器+多个工作节点）共同工作。这意味着，一旦Citus与新版PG完成兼容性适配，绝大多数上游改进无需额外开发即可“自动生效”。在Citus 14.0中，PG 18的以下能力被直接带入分布式场景： 异步I/O：分片密集的分布式集群中，顺序扫描、位图堆扫描和VACUUM操作从AIO中获得显著加速； 跳跃扫描：在多租户应用中，跳过分布列前缀的查询也能有效使用多列索引； uuidv7()：时间有序的UUID在各分片间生成，减少跨分片索引的随机写入开销。 1.2 仍需Citus定制的领域 尽管如此，某些复杂功能仍需Citus团队进行专项适配——包括JSON_TABLE()在分布式查询中的支持、DDL传播的正确性验证，以及PG 18新增时态约束在分片语义下的一致性保证。对于已经或计划采用Citus分片架构的企业而言，14.0是一个值得规划的升级节点。 二、Apache Cloudberry 2.1.0：MPP数据仓库的开源新力量 2026年4月，Apache Cloudberry（孵化中）发布了2.1.0版本，这是继2.0.0正式进入Apache孵化器后的首个重要更新。 Cloudberry的核心定位是MPP数据仓库，继承自Greenplum Database最后一代开源代码，专为大规模分析型工作负载和AI场景设计。2.1.0的核心突破包括： UDP2互联协议：全新实现的计算节点间通信协议，提升分布式查询的执行效率； ORCA优化器增强：支持CTE剪枝和部分聚合下推，多项正确性与内存修复； PAX列存格式LZ4压缩：提升存储效率，配合I/O和内存管理优化； 快速ANALYZE：针对追加优化表的统计信息收集加速，解决大规模环境中的运维瓶颈； MCP服务器：便于与LLM工具和AI工作流集成。 Cloudberry的出现填补了PG生态在“分析型MPP数据仓库”领域的空白。与Citus侧重OLTP/HTAP场景的分片架构不同，Cloudberry沿袭了Greenplum的列式存储与大规模并行执行引擎，与PG 18/19的内核新特性形成互补。值得注意的是，其内核版本目前仍基于PG 14.x，团队正积极推进向PG 16.x的升级，未来内核版本的追赶将是Cloudberry的关键看点。 三、Google Cloud：推动逻辑复制迈向“主动-主动”架构 Google Cloud在2026年初发布的一份社区贡献报告，勾勒出一条清晰的演进路径：让PostgreSQL的逻辑复制从主-从模式走向主动-主动（active-active）架构。 3.1 自动冲突检测：打破双向复制的长期瓶颈 逻辑复制的传统局限在于双向写入场景下，冲突更新可能导致复制中断。Google Cloud工程师向PostgreSQL上游贡献的关键能力是自动冲突检测——数据库在复制过程中可自动识别行级冲突，无需人工干预。这一能力是多节点写入场景的核心突破，也是迈向主动-主动架构的前提条件。 3.2 序列复制与pg_upgrade优化 其他关键贡献包括：将逻辑复制范围从表数据扩展到序列，大幅减少迁移或版本升级时的手动同步需求；修复订阅管理中的自死锁问题；对pg_upgrade的大对象管理优化，缩短大规模部署的升级时间。此外，Google还正在研发复制结构化冲突日志、pg_dump并行数据导出等未来能力。 社区对此反响热烈：Franck Pachot指出，带冲突解决的双向逻辑复制与CockroachDB/YugabyteDB等分布式SQL存在不同的一致性模型基础——前者遵循“最后写入胜出”，后者提供严格ACID语义。但更多观点认为，当超大规模云厂商将主动-主动复制这类企业级特性贡献到上游时，标志着PostgreSQL已成为无可争议的企业默认选择。 四、阿里云Serverless Pro：存算分离的工程化落地 如果说Google Cloud从“复制”维度推动分布式演进，阿里云则从“架构”维度给出了另一条答案——Serverless Pro模式，以存算分离为底座，重塑云原生PostgreSQL的弹性边界。 4.1 从有状态到无状态：架构的范式迁移 传统AnalyticDB PostgreSQL版采用Master/Segment架构，计算节点绑定本地ESSD，数据增长带来存储成本的线性上涨，计算节点有状态导致扩缩容慢；一写多读只能通过“新建集群+复制数据”实现，周期长且存储成本成倍增加。 Serverless Pro模式将持久化数据统一沉降到OSS对象存储，本地ESSD仅用于缓存与临时数据，使计算层趋于无状态。计算与存储解耦后，算力可独立扩缩——峰值快速拉起，低谷及时回收，存储按需付费，避免被本地盘长期绑定。 4.2 Virtual Warehouse：读写分离的极致版本 基于共享存储底座，Serverless Pro支持“主集群+多Virtual Warehouse（VW）”的多集群共享存储架构。主集群处理写入任务，只读业务由独立VW承载，大查询不再抢占主集群资源。创建VW无需复制数据，读扩展从传统“天级数据复制”缩短为“分钟级资源拉起”；多个VW共享同一份底层数据，避免为每个只读集群重复购买存储。 4.3 Log-as-Database的设计思想 Serverless Pro的底层基于“Log-as-Database”思想：将数据库的“随机写Page”转化为WAL的“顺序写”，由存储侧异步回放WAL生成数据页，使最终数据长期驻留在OSS上。其四层架构（计算节点→Log Store→Page Store→OSS）清晰呈现了存算分离的工程全貌。 阿里云已于2026年3月30日正式下线旧版Serverless模式，Serverless Pro成为其云原生数据仓库的标准入口。 五、其他云原生分布式力量 方案 架构路线 关键特点 适用场景 EDB Postgres Distributed 原生分布式 高可用、性能与弹性，全球级分布式支持 企业级全球部署 CloudNativePG 1.29 Kubernetes Operator 8k+ GitHub星标，扩展模块化解耦，供应链安全 K8s环境PG运维 Stolon K8s HA管理器 etcd集群状态管理，自动故障切换 容器化高可用部署 Amazon Aurora PostgreSQL 云托管存算分离 5倍吞吐量，自动存储扩展，Blue/Green切换 云上托管OLTP CockroachDB 协议兼容版 PG线缆协议兼容，Raft分布式共识，跨地域强一致 全球分布式事务 TiDB for PostgreSQL 协议兼容版 TiDB分布式架构 + PG兼容API层，代码迁移成本低 MySQL/PG混合迁移 协议兼容版指在API层面模拟PostgreSQL通信协议、底层为自研架构的产品类型。这类产品基于云原生基础设施构建，可提供跨区域强一致性与水平读写扩展等原生PG难以实现的能力。 六、总结与展望 回顾2026年云原生PostgreSQL分布式架构的演进全景，四条主线贯穿始终： 第一条主线：分片扩展的持续进化。 Citus 14.0完成了PG 18的完整适配，让异步I/O、跳跃扫描等底层性能红利在分布式集群中兑现。作为分片扩展的代表，Citus持续巩固其在OLTP/HTAP场景的领先地位。 第二条主线：MPP数据仓库的生态新生。 Apache Cloudberry 2.1.0的发布填补了PG生态在分析型MPP领域的空白。继承自Greenplum的列存引擎与大规模并行执行能力，为大数据分析提供了开源新选择。 第三条主线：云厂商驱动的基础能力跃迁。 Google Cloud推动逻辑复制迈向主动-主动架构，阿里云Serverless Pro以存算分离重塑弹性边界。云厂商不仅将PG作为服务对外提供，更将内部大规模运维的实践经验反向贡献给上游社区。 第四条主线：多样化分布式生态的百花齐放。 EDB Postgres Distributed面向企业级全球部署、CloudNativePG成为K8s上PG运维的事实标准、CockroachDB与TiDB等协议兼容版以自研分布式架构满足极端扩展需求——不同的架构路径服务于不同的场景诉求，共同构成了2026年PG分布式生态的完整图景。 回看过去一年的分布式架构演进，一个清晰的趋势正在浮现：PostgreSQL正在从“一个可以被分布式的数据库”演进为“一个原生具备分布式能力的数据平台”。 这种变化不仅体现在技术能力上——存算分离、主动-主动复制、MPP分析引擎；更体现在生态格局上——从单一的分片扩展，走向多种架构路线共存的分布式生态系统。 对于企业架构师和技术决策者而言，2026年的选择前所未有的丰富：是采用轻量级的分片扩展（Citus），还是部署完整的MPP数据仓库（Cloudberry）；是依赖云厂商托管的Serverless模式，还是基于Kubernetes自建云原生运维体系——每一条路径都有成熟的开源生态和商业支持作为后盾。 这正是云原生PostgreSQL时代最值得关注的价值：企业可以在不牺牲PostgreSQL生态兼容性的前提下，根据自身的规模、场景和运维能力，选择最适合的分布式演进路径。 📌 下期预告：第五期——PostgreSQL扩展开发实战：用Rust构建自己的PG扩展 从pgvector到VectorChord，从ParadeDB到Citus，PG生态的强大生命力源自其可扩展的内核架构。第五期我们将深入扩展开发实战，以Rust为开发语言，从零构建一个完整的PG扩展，带你掌握PostgreSQL扩展开发的全流程——从环境搭建到Cargo integration，从数据类型定义到性能优化。 （本文数据截至2026年4月，最新动态请以各项目官方发布为准。）

第三期：PG 19 新特性全景解读 从原生图查询到执行计划“锁死”，2026年最值得关注的数据库版本来了 2026年4月8日，PostgreSQL 19正式进入特性冻结阶段，意味着所有新功能已锁定，后续开发重心全面转向稳定化测试与Bug修复。目标发布时间为2026年9月，Beta测试预计于5月启动。随着Bruce Momjian完成PG 19发布说明的首个草稿，这个年度重磅版本的全貌正逐渐清晰。 PG 19延续了PG社区“插件验证→内核化收敛”的演进路径，多个曾在扩展生态中充分验证的能力正式进入内核——SQL/PGQ图查询、原生REPACK表重整、执行计划锁定等重磅功能同时落地，标志着PostgreSQL在“多模数据平台”的战略方向上迈出了关键一步。 一、SQL/PGQ图查询：关系型数据库的“图思维”革命 1.1 从扩展到内核：图查询的“毕业”时刻 PG 19最受瞩目的新特性，无疑是SQL/PGQ属性图查询的原生支持。此前，在PostgreSQL中实现图查询主要依赖Apache AGE扩展、AgensGraph分支或pgRouting算法库。PG 19将图查询能力直接纳入内核，用户无需安装任何扩展，即可使用标准SQL语法在PostgreSQL内部执行属性图查询。 SQL:2023标准引入了SQL/PGQ，首次允许关系型数据库将图遍历视为一等公民的声明式操作。PG 19对这一标准的落地，不仅是语法层面的支持，更是PostgreSQL从关系型数据库向多模数据平台演进的重要里程碑。 1.2 实际应用场景：知识图谱与社交网络 图查询的核心价值在于表达实体之间复杂的关联关系。一个典型的场景是知识图谱——如“查找A的关联人员中，谁与B有过直接交易”这类多层关联查询，在传统SQL中需要复杂的自连接与递归CTE，在图查询中则可以用一条清晰的路径表达式完成。社交网络关系分析、推荐系统的协同过滤、欺诈检测中的资金链路追踪等场景，都能从中直接受益。 1.3 与向量检索形成“语义+关系”双轮驱动 结合上一期讨论的pgvector向量检索能力，PG 19的图查询进一步丰富了数据库的表达范式。向量检索擅长“模糊语义匹配”（如“找出与这张图片相似的图片”），图查询擅长“精确关系遍历”（如“找出这张图片的所有上传用户的好友关系”）。两者结合，PostgreSQL在多模数据场景下的覆盖广度达到了前所未有的水平。 二、pg_plan_advice：执行计划的“终极掌控” 2.1 DBA的噩梦：执行计划突然跑偏 一条长期稳定运行的核心SQL，可能因为统计信息更新、数据库版本升级、配置参数调整，突然被查询规划器选择了错误的执行计划，导致性能从毫秒级暴跌至秒级甚至分钟级。此前，DBA只能通过第三方插件pg_hint_plan、重写SQL或调整全局参数来临时解决，不仅门槛高、兼容性风险大，还缺乏官方原生的稳定支持。 2.2 路径生成策略：扩展规划器的底层钩子 PG 19引入的路径生成策略（Path Generation Strategies）机制，为插件提供了在查询规划器最早阶段影响决策的能力。传统规划器的工作流程是先产生多条路径（如顺序扫描、索引扫描、Hash连接等），再通过成本比较淘汰劣质路径。但由于规划器可能在成本比较早期就丢弃一些路径，扩展插件在旧框架下很难强制保留特定计划。路径生成策略机制解决了这一根本性问题，使插件能够在内核层面稳定地影响规划决策。 2.3 pg_plan_advice使用方法 pg_plan_advice作为contrib模块随PG 19一同发布，提供原生的执行计划锁定能力。核心使用流程如下： 第一步：获取计划建议字符串 EXPLAIN (COSTS OFF, PLAN_ADVICE) SELECT * FROM join_fact f JOIN join_dim d ON f.dim_id = d.id; 系统会返回类似如下的建议字符串： JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d) 其中：JOIN_ORDER(f d)指定以f表为驱动表、d表为关联表；HASH_JOIN(d)指定d表作为哈希连接的内表；SEQ_SCAN(f d)指定对两表均使用顺序扫描；NO_GATHER(f d)指定不将两表置于并行Gather节点之下。 第二步：应用计划建议 通过GUC参数将建议字符串应用到后续查询中： SET pg_plan_advice.advice = 'JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d)'; 用户还可以编辑建议字符串，仅保留需要强制生效的部分。例如，仅需控制连接顺序时，可仅设置JOIN_ORDER部分。 2.4 对pg_hint_plan生态的影响 路径生成策略机制的最大受益者是pg_hint_plan等第三方提示插件。在新框架下，pg_hint_plan预计可减少约2500行代码，实现更简洁、更可靠的执行计划提示能力。这也标志着PostgreSQL从“抗拒查询提示”到“开放官方扩展接口”的重要转变。 三、分区管理的“平民化”：MERGE/SPLIT PARTITIONS 3.1 从复杂脚本到一行命令 分区表的动态管理一直是PostgreSQL DBA的痛点。在PG 19之前，将多个分区合并为一个，或将一个大分区拆分为多个，往往需要手动创建新分区、迁移数据、删除旧分区等一系列复杂操作，极易出错。PG 17曾尝试引入分区合并与拆分命令，但补丁在发布前不久被回退。PG 19以更稳健的实现方式完成了第二次尝试。 3.2 典型操作示例 以按月份分区的航班预订表为例，合并去年第四季度的三个分区： -- 合并三个月份分区为一个季度分区 ALTER TABLE bookings_range MERGE PARTITIONS (p2025_10, p2025_11, p2025_12) INTO p2025; -- 将季度分区重新拆分为月份分区 ALTER TABLE bookings_range SPLIT PARTITION p2025 INTO ( PARTITION p2025_10 FOR VALUES FROM ('2025-10-01') TO ('2025-11-01'), PARTITION p2025_11 FOR VALUES FROM ('2025-11-01') TO ('2025-12-01'), PARTITION p2025_12 FOR VALUES FROM ('2025-12-01') TO ('2026-01-01') ); 3.3 当前限制与未来展望 目前，MERGE和SPLIT PARTITIONS命令会在整个执行期间对父表加排他锁，因此不应在业务高峰期运行。但这一功能为未来的锁级别优化和并行执行奠定了坚实基础。对于需要定期调整分区策略的数据生命周期管理场景，这一特性显著降低了运维复杂度。 四、逻辑复制：告别“重启恐惧症” 4.1 动态WAL级别调整 长期以来，PostgreSQL逻辑复制和逻辑解码（CDC）的使用存在一个令人困扰的痛点：必须在数据库启动前将wal_level设置为logical并重启实例。这意味着即便没有任何逻辑复制任务运行，数据库也要持续承担logical级别WAL日志带来的额外I/O和存储开销。 PG 19彻底解决了这一问题。系统现在可根据逻辑复制槽的存在与否，自动动态调整WAL级别：创建第一个逻辑复制槽时，有效WAL级别自动提升至logical；当最后一个逻辑槽被删除或失效后，有效级别降回replica。新增的只读GUC参数effective_wal_level可用于监控当前实际生效的WAL级别。 4.2 发布订阅的精细控制 PG 19还允许在ALTER PUBLICATION中使用EXCEPT TABLE子句，实现对发布订阅中特定表排除的精细控制。这一改进在租户隔离和选择性数据同步场景中尤为实用。 五、pg_dump增强：统计信息的“完整闭环” 5.1 从PG 18到PG 19：统计信息能力的持续进化 PG 18引入了表级和列级统计信息的导出与恢复能力，解决了大版本升级后因统计信息丢失导致执行计划不准的“升级即事故”风险。PG 19在此基础上更进一步，新增了扩展统计信息（Extended Statistics）的完整支持。 5.2 扩展统计信息的导出与恢复 通过--statistics参数，pg_dump现在可以导出由CREATE STATISTICS创建的三种扩展统计类型（ndistinct、dependencies和MCV），并通过pg_restore_extended_stats函数在目标数据库中恢复。 使用示例： # 仅导出统计信息（不含表结构和数据） pg_dump --statistics-only -d production_db > stats.sql # 导出表结构+统计信息（用于测试环境搭建） pg_dump --schema-only --statistics -d production_db > schema_with_stats.sql 导出文件为纯SQL格式，包含三个还原函数pg_restore_relation_stats（表级）、pg_restore_attribute_stats（列级）和pg_restore_extended_stats（扩展级）的调用语句，可直接在目标环境执行导入。 5.3 生产环境对齐的“杀手级”能力 这一特性对生产环境问题复现和测试环境对齐具有极高价值。DBA可以从生产库导出精准的统计信息并在测试库中恢复，使查询规划器在两个环境中做出相同的决策，从根本上消除“生产复现不了”的困境。 六、REPACK内核化：表膨胀治理进入新时代 6.1 从外部工具到原生命令 pg_repack长期以来作为PostgreSQL社区最受欢迎的第三方运维工具之一，以“在线重整表数据、仅需最少锁”的能力解决了VACUUM FULL需要排他锁的痛点。PG […]

第二期：PostgreSQL向量检索深度剖析——从pgvector到VectorChord 当向量检索从“能用”走向“好用”，PG生态如何重塑AI应用的数据底座 在第一期中，我们提到PostgreSQL正在经历一场从关系型数据库到综合性数据平台的深刻转型。而这场转型最核心的驱动力之一，正是向量检索能力的爆发。2026年，PostgreSQL在向量检索赛道上已完成从“追赶到引领”的角色转换。根据DB-Engines 2025年11月的数据，PostgreSQL在向量数据库细分赛道中已直接冲进前三——与专业向量数据库同台竞技。这背后，是PG社区与生态力量合力完成的一场关于效率、成本和架构的全面进化。 一、pgvector：从奠基者到持续进化的“事实标准” 1.1 为何pgvector成为AI工作流的中心？ pgvector之所以能在短短几年内成为AI应用开发的事实标准，核心原因在于它让向量检索与关系型数据库的能力实现了“无缝对接”。开发者可以在一个PostgreSQL实例中同时处理以下需求： 存储文本的embedding向量，并在其上构建相似度搜索； 关联用户ID、商品类别、状态等元数据进行复杂过滤； 利用ACID事务保证数据一致性； 借助Point-in-Time Recovery（PITR，即时间点恢复）、流复制等高可用特性保障生产稳定。 对大多数企业级AI应用而言，这些能力远比纯粹的向量检索性能更重要。 1.2 索引体系：IVFFlat与HNSW的选择之道 pgvector提供两类核心近似最近邻（ANN）索引，分别对应不同的使用场景： IVFFlat（倒排文件索引）：将向量空间划分为多个聚类（lists）。查询时只搜索与目标向量最近的若干聚类，而非全表扫描。构建速度快，内存占用低，适合数据频繁更新的场景。 HNSW（分层导航小世界）：构建多层图结构，查询时从顶层向下贪婪搜索。检索精度更高，但构建时间显著更长，内存消耗更大。 两者之间不存在“绝对优胜”，真正有意义的权衡在于：你的数据更新频率有多高、可接受的内存预算有多少、以及业务要求的召回率和延迟标准是什么。 1.3 pgvector 0.8.0：从“基础可用”到“生产级可用” 2025年的pgvector 0.8.0版本是一次重要的跨越式升级： 性能飞跃：相较0.7.4版本，特定查询模式的性能提升高达5.7倍，在Amazon Aurora PostgreSQL上甚至实现了9倍查询加速和100倍搜索结果相关性提升； 迭代扫描（iterative_scan）：解决了困扰多时的“过过滤”（overfiltering）问题——即结合向量搜索与SQL过滤时，结果被过度裁剪甚至返回空集的场景； 成本估算优化：优化器能够更智能地选择执行路径，如在复杂过滤场景下优先使用B-tree而非HNSW。 1.4 安全与运维：pgvector 0.8.2的关键补丁 2026年2月，pgvector 0.8.2发布，修复了并行HNSW索引构建中的缓冲区溢出漏洞（CVE-2026-3172），恶意用户可通过该漏洞泄露敏感数据或导致数据库崩溃。这一事件提醒我们，向量检索扩展的成熟度不仅体现在性能上，更体现在安全响应和运维稳健性上。 二、VectorChord：磁盘优先架构如何改变游戏规则 如果说pgvector是向量检索在PG生态中的奠基者，那么VectorChord正在扮演“破局者”的角色。作为pgvecto.rs的继任者，它由同一团队开发，目标只有一个：让PostgreSQL的向量检索真正能上到十亿级规模。 2.1 为什么需要VectorChord？ pgvector的HNSW索引尽管性能出色，但在PostgreSQL的内核架构中面临一个根本性矛盾。HNSW要求索引常驻内存才能保证高性能，而PostgreSQL的表/索引模型、MVCC、VACUUM等机制与HNSW的图结构之间存在天然的不匹配： 插入成本高昂：插入单个向量可能触发多层、多节点的级联调整； 删除处理复杂：删除节点后需重新插入所有邻居以保持图的连通性，维护成本极高。 当数据规模达到千万甚至亿级时，这套架构的运维成本会急剧膨胀。 2.2 技术突破：IVF + RaBitQ组合方案 VectorChord的核心方案是IVF + RaBitQ量化技术： IVF聚类：向量被路由到粗粒度聚类中，查询时只在相关聚类中搜索； RaBitQ量化：在每个聚类内存储压缩后的量化码而非原始高维浮点数，查询时主要在压缩码上执行查表和整数运算。 这一设计带来的收益是质变性的——索引主体存储在磁盘而非内存中，使十亿级向量检索成为可能。 2.3 令人瞩目的性能指标 索引构建：在16 vCPU机器上，1亿向量索引构建时间不足20分钟；同等规模下，pgvector HNSW需要超过50小时； 存储成本：每1美元可存储40万向量——相同成本下，存储量是Pinecone优化存储的6倍，是pgvector的26倍； 查询能力：仅需32GB内存即可查询1亿个768维向量，P50延迟低至35ms，top10召回率高达95%； 高维支持：向量维度上限高达60,000，可轻松适配text-embedding-3-large等高维模型。 2.4 与pgvector的生态兼容 值得注意的是，VectorChord并非pgvector的替代品，而是补充者。它完全兼容pgvector的数据类型和语法，开发者可以在不修改应用代码的前提下引入VectorChord索引以获得性能提升。在实际部署中，两者可以并存于同一数据库，由开发者在不同场景中选择最合适的索引策略。 三、生态融合：向量检索与全文搜索的“双向奔赴” 单一模态的检索在真实场景中往往力不从心。2026年，PG生态中最值得关注的趋势之一是向量检索与全文搜索的深度融合。 3.1 ParadeDB：PostgreSQL原生替代Elasticsearch ParadeDB是一个基于PostgreSQL的现代Elasticsearch替代方案，其口号是“Postgres for Search & Analytics”。它通过pg_search扩展带来了BM25全文搜索、密集与稀疏向量搜索以及分面搜索能力。在ParadeDB的实践中，BM25的词汇精准度与pgvector的语义理解能力形成了完美互补。 3.2 混合搜索（Hybrid Search）策略 混合搜索的核心问题是如何融合两类不同维度的相关性得分。行业公认的最佳实践是RRF（Reciprocal Rank Fusion，倒数排名融合）：综合计算BM25的词汇排名和向量相似度的语义排名，生成融合后的最终结果。VectorChord Suite更进一步，在同一发行版中内置了vchord（IVF+RaBitQ向量索引）、pg_tokenizer（文本分词）和vchord_bm25（BM25检索），提供一体化的混合搜索体验。 3.3 全文搜索的演变：从tsvector到BM25 PostgreSQL原生的全文搜索基于tsvector/tsquery，其排名函数ts_rank仅考虑文档本身的词频，缺乏对全局语料统计的理解——无法区分高频通用词与低频关键字的权重差异。BM25通过词频（TF）、逆文档频率（IDF）和文档长度归一化三者融合解决了这一问题，成为现代搜索引擎的事实标准。pg_search扩展将BM25能力直接带入PostgreSQL内核。 四、总结与展望 回顾本期内容，我们可以清晰地看到PostgreSQL向量检索生态的三个演进层次： pgvector提供了“能用”的基础——向量类型、标准索引和SQL接口，已被云厂商广泛集成； VectorChord带来了“好用”的突破——磁盘优先架构大幅降低了大规模向量检索的门槛； 混合检索生态正在走向“全能”——向量检索与全文搜索的融合，使PostgreSQL真正具备了覆盖多种检索场景的统一平台能力。 2026年的向量检索战场，胜负的关键已不再是“谁跑得更快”，而是“谁能以更低的成本、更简洁的架构，支撑AI应用全生命周期”。PostgreSQL生态凭借其30年积累的稳定性、活跃的开源社区和灵活可扩展的内核架构，正逐渐成为AI应用数据底座的首选。 📌 下期预告：第三期——PG 19新特性全景解读 随着PG 19正式进入特性冻结阶段，我们将全面解读SQL/PGQ图查询、pg_plan_advice引导系统、分区管理增强等重磅特性，并深入探讨这些新能力将如何改变PostgreSQL的未来格局。 （本文数据截至2026年4月，最新动态请以各项目官方发布为准。）

2026，PostgreSQL的“基因进化”：从异步I/O到AI原生 一场正发生在你身边的数据库深度变革 提到PostgreSQL，很多人脑海中浮现的印象是“功能丰富、稳定可靠、SQL兼容性好”。但如果只停留在这些标签上，你可能正在错过一场正在发生、关乎数据库底层基因层面的深刻变革。 2026年，随着PostgreSQL 18的正式落地和PostgreSQL 19进入特性冻结阶段，PG社区正在推进的远不止是一个“新版本”——而是一场从内核架构到AI生态的系统性重塑。 一、PostgreSQL 18：一个“改写底层基因”的里程碑 在过去的二十年里，PostgreSQL的性能演进一直遵循着相对温和的节奏。但PG 18带来了一个根本性的突破。 1.1 异步I/O：破局二十年同步阻塞宿命 异步I/O（Asynchronous I/O，即数据库一次性发起多个I/O请求，CPU无需等待每个请求依次返回即可继续执行）是PG 18最重磅的底层性能变革。在此之前，PostgreSQL在数据读取上高度依赖操作系统预读机制，而操作系统并不理解数据库的实际访问模式。PG 18全新引入的AIO子系统允许数据库一次性并发发起多个I/O请求而非依次等待，在顺序扫描、位图堆扫描和VACUUM等读取密集型场景下表现尤为突出。 这一变革在云存储场景下的价值尤为显著。云盘底层需通过网络访问，网络延迟远高于本地NVMe SSD。PG 18之前，这些大I/O操作使用同步方式执行，大量数据库时间消耗在网络等待上。PG 18的异步I/O彻底改变了这一局面。根据早期基准测试，在特定读取密集型场景下性能提升可达2至3倍。 💡 深度洞察：异步I/O的价值在云环境中被放大了数倍。云原生数据库时代，本地NVMe已是过去式，对象存储和网络附加存储正成为主流。PG 18的AIO框架不仅是性能优化，更是对云原生架构的前瞻性适配。 1.2 跳跃扫描：让多列索引真正“多用”起来 PG 18的跳跃扫描（Skip Scan）解决了多列B-tree索引的一个长期痛点——当查询跳过索引的第一个列时无法有效利用索引。例如，在订单表索引(customer_id, order_date)上，查询特定日期的所有订单（不指定customer_id）现在也能高效走索引。Citus 14.0的发布直接利用了这一特性，显著改善了多租户查询场景的表现。 1.3 uuidv7()：索引碎片化的终结者 传统UUIDv4完全随机，导致B-tree索引严重碎片化。PG 18原生支持的uuidv7()结合时间戳与随机数生成时间有序的UUID，优化索引局部性，显著提升写入性能并减少索引膨胀。 1.4 时态约束：数据完整性进入“时间维度” PG 18引入的WITHOUT OVERLAPS和PERIOD时态约束机制，首次允许开发者定义基于时间区间的数据完整性规则，维护跨时间段的主外键关系。这是SQL标准演进方向的重要标志，为历史数据管理和时间旅行查询提供了语法层面的原生支持。 1.5 PL/Rust：让存储过程跑出“系统级性能” PL/Rust作为可加载的过程语言扩展，允许开发者用Rust编写PostgreSQL函数，编译为原生机器码执行，性能远超解释型过程语言。随着Rust在系统编程领域持续升温，PL/Rust为PG生态开辟了一条“性能敏感型存储过程”的新路径。 1.6 OAuth支持与现代SQL标准增强 PG 18原生支持OAuth认证，可与现代SSO/OAuth流程无缝集成。同时，JSON_TABLE()增强了对分布式查询的支持，虚拟生成列成为默认行为，节省存储空间并消除写入开销。RETURNING子句也得以同时访问OLD和NEW值，审计日志实现更为便捷。 二、PostgreSQL 19：2026年值得期待的新篇章 PG 19的目标发布时间为2026年9月，目前已于2026年4月8日正式进入特性冻结阶段，Beta版本预计2026年5月启动。 2.1 执行计划的“引导系统”：pg_plan_advice pg_plan_advice是PG 19引入的一个contrib模块，提供稳定执行计划选择的设施。其核心价值在于对查询优化器的可扩展性重塑——底层路径生成策略（path generation strategies）的开放为外部插件提供了影响查询规划器早期决策的能力。传统pg_hint_plan可能需要数千行代码实现的功能，在新框架下大幅简化。这让DBA“锁死”正确执行计划的能力从“hack”走向“官方支持”。 2.2 SQL/PGQ图查询：原生图能力的里程碑 PG 19有望引入SQL/PGQ（Property Graph Query）支持，使开发者能够使用标准SQL语法直接在PostgreSQL内执行属性图查询。这标志着PG正从一个纯关系型数据库，逐步进化为融合关系、文档、向量、图的多模数据平台。 2.3 其他值得关注的特性 PG 19在分区管理上支持合并与拆分分区，逻辑复制增强动态WAL级别调整和改进延迟追踪，pg_dump/pg_restore现支持扩展统计信息导出，监控能力新增autoanalyze统计与pg_stat_statements的最后执行时间等。此外，pg_repack索引重组功能的内核化也在推进中，DBA维护工作将更加平滑。 三、AI与扩展生态：PostgreSQL的“无限可能” PG的真正力量不仅来自内核，更来自其庞大的扩展生态。 3.1 pgvector：从“插件”到“原生基因” pgvector作为PG生态中最核心的向量扩展，已支持L2距离、内积和余弦距离等多种相似度搜索算法，并支持IVFFlat和HNSW等多种索引类型。截至2026年，几乎所有主流云RDS均已原生支持pgvector。vectorize扩展甚至将向量化流程简化为两个函数调用，自动处理文本到向量的转换和LLM集成。 与此同时，VectorChord作为pgvector兼容的新兴扩展，以磁盘高效设计著称，官方宣称可在20分钟内完成1亿级向量索引构建，在高性能向量检索领域值得持续关注。 3.2 ParadeDB & pg_lakehouse：数据湖与搜索引擎的“PG化” ParadeDB是一个构建于PG之上的Elasticsearch替代方案，支持BM25全文搜索、混合搜索（词汇+向量）和多面搜索，完全开源并在GitHub上积累超8,000星标。pg_lakehouse扩展则将PG转化为基于对象存储的分析查询引擎，原生支持Delta Lake和Iceberg表格式。两者结合，使PG真正具备了数据湖分析和全文检索引擎的能力。 💡 深度洞察：这套组合意味着什么？一个PostgreSQL实例可以同时承担事务处理+向量检索+全文搜索+数据湖分析四种负载。过去需要Elasticsearch、专门向量数据库和Spark的数仓架构，如今在一个数据库内便可实现。 3.3 云原生分布式生态全面繁荣 2026年的PG分布式生态呈现出多元化繁荣态势。Citus 14.0已完成对PG 18的完整适配，将AIO、跳跃扫描等特性带入分布式场景。Apache Cloudberry 2.1.0作为基于PG的MPP数据库，引入UDP2互联协议和PAX列存格式的LZ4压缩支持。主流云厂商也在积极贡献，Google Cloud在2025年下半年重点推动了逻辑复制向主动-主动架构演进，包括自动冲突检测和序列复制能力。此外，阿里云推出的Serverless Pro模式结合MPP技术与Serverless能力，为云上弹性分析开辟了新方向。 结语：PostgreSQL的“平台化”时刻 2026年的PostgreSQL正在完成一次身份跃迁——从一款优秀的关系型数据库，进化为覆盖事务处理、分析查询、向量检索、全文搜索、图查询和时空数据处理的综合性数据平台。 PG社区的进化路径有其独特逻辑：插件生态验证需求 → 内核化完成收敛 → 逐步成为标准功能。异步I/O、跳跃扫描、时态约束、图查询……今天内核中的每一个新特性，都曾在扩展生态中经历过充分验证。这种“先实验后内核”的演进模式，既保证了稳定性，又确保了每一次内核更新都是解决真实问题的有效方案。 PG 18已经为这轮变革打下了地基。PG 19则正在将上层建筑逐一搭建起来。当数据平台“大一统”的蓝图逐步兑现，2026年正是重新认识PostgreSQL的最佳时机。 📌 本文作为系列开篇，后续将围绕以下专题深入展开： 第二期：PostgreSQL向量检索深度剖析——从pgvector到VectorChord 第三期：PG 19新特性全景解读（正式发布后） 第四期：云原生PostgreSQL的分布式架构演进 第五期：PostgreSQL扩展开发实战——用Rust构建自己的PG扩展 （本文数据截至2026年4月，最新动态请以PostgreSQL官方发布为准。）

Oracle Database 23ai/26ai 新特性系列 —— 第六期：企业级可用性、性能自治与开发体验进化 在本系列的第五期中，我们从 SQL Firewall 到抗量子加密，系统解读了 AI 时代的全面防护体系。如果说安全体系解决了“谁能访问数据”的问题，那么企业级可用性与性能优化解决的则是“系统能否持续稳定运行”的问题——在金融交易、实时风控、在线支付等对停机零容忍的场景中，可用性的每一点提升都对应着真金白银的价值。 Oracle Database 26ai 在 23ai 奠定的 AI 能力基础之上，推出了一系列面向企业级高可用和性能自治的增强，涵盖可用性分级体系、In-Memory 列存储的自动智能管理、图分析的 SQL 标准化、开发者语法增强以及自治服务的新能力。这些特性共同构成了 26ai 的企业级能力拼图。 一、可用性分级：铂金级与钻石级 对于承担企业核心业务的数据库而言，高可用性（High Availability）不是锦上添花，而是生死攸关的基础能力。Oracle Database 26ai 在全球分布式数据库和 RAC（Real Application Clusters）能力的之上，正式建立了三层可用性分级体系——从已广泛部署的黄金级，到新推出的铂金级，再到针对极限场景的钻石级。这套体系帮助企业根据业务重要性和成本约束选择合适的可用性方案。 1.1 黄金级：行业标准的高可用 黄金级可用性基于 Oracle RAC 和 Active Data Guard 构建，已在全球大多数大型企业和政府机构中广泛部署。RAC 支持应用在多台计算机之间透明扩展，并防护单机故障；Active Data Guard 则提供跨站点、跨数据中心和跨数据损坏的保护。这一层级已能实现单机应用的秒级灾难恢复和高吞吐多节点集群的低个位数分钟级恢复时间，覆盖了绝大多数企业生产系统的需求。 1.2 铂金级：30 秒内恢复，4 倍性能飞跃 26ai 最大的突破在于铂金级可用性。在 Exadata 平台上，铂金级可用性的灾难恢复时间可做到 30 秒以内，即便是跨区域的高吞吐多节点集群也不例外。与此前版本的数据相比，这比 Oracle Database 19c 快出 4 倍，更关键的是——无需任何应用修改。 铂金级可用性的另一项价值在于其普适性：所有在 Oracle Active Data Guard 和 RAC 上运行 26ai 与 Exadata 的客户，无论工作负载是简单的单机应用，还是运行在大型 RAC 集群上的超高吞吐任务，都可以零成本、零应用变更地直接受益。从黄金级升级到铂金级，只需升级 Oracle 数据库和 Exadata 软件，无额外费用。 1.3 钻石级：3 秒内恢复，感知不到的停机 对于实时信用卡处理、高频交易、支付清算等极度敏感的工作负载，铂金级的 30 秒恢复时间依然不够——每一次故障造成的每一秒中断都意味着巨大的经济损失。 钻石级可用性专为此类应用设计。它利用 GoldenGate 或 Oracle Globally Distributed AI Database，在数据中心或区域之间实现数据库的逻辑复制，构建双活分布式集群，能够极快地检测故障并恢复——通常只需 3 秒，人类的感知完全捕捉不到停机。钻石级可用性实现了零数据丢失和亚秒级恢复，将“高可用”推向“零感知中断”的新高度。 1.4 分级体系的战略意义 黄金级解决的是“大多数企业够用”的标准问题，铂金级将恢复时间从分钟级压缩到 30 秒以内，满足金融、电信、政务等对高可用有严格要求的场景，而钻石级则以 3 秒为标杆，将可用性推向近乎实时的水平。这套分级体系让企业可以根据业务关键程度和成本预算自由选择可用性层级——这正是 26ai 在企业级高可用方面的核心主张。 二、In-Memory 性能自治：数据库自管理的新高度 In-Memory 列存储是 Oracle Database 中提升分析查询性能的核心技术。26ai 对这一技术的演进集中在“自治”二字上——从需要人工干预的手动配置，迈向数据库根据工作负载自动决策的新阶段。 2.1 自动启用 In-Memory 特性 在 26ai 中，AIM 可以根据增强的工作负载分析算法，自动创建 Join Groups、启用 In-Memory Optimized Arithmetic、向量优化和 Bloom filter 优化。这项增强解决了长期困扰 DBA 的一个痛点：在传统模式下，决定哪些表、哪些列应该放入 In-Memory 列存储，哪些优化特性应该开启，需要大量的经验判断和反复测试。现在，数据库可以通过分析实际运行的 SQL 模式，自行做出这些优化决策。 AIM 的另一个重要改进是引入了 DML 开销的评估机制。此前，AIM 只考虑查询性能的提升，不评估 In-Memory 填充对象带来的 DML（插入/更新/删除）开销。在混合负载环境中，这种偏颇可能导致整体性能反而下降。26ai 解决了这一缺陷，使 AIM 能够在读写混合工作负载中做出更平衡的决策。 2.2 自动 In-Memory 大小调整 26ai 的另一项重要创新是将 IM 列存储纳入自动共享内存管理的范畴。ASMM 可以根据整体数据库工作负载的需求，自动扩展或收缩 IM 列存储的大小。这意味着数据库能够在内存资源有限的情况下，动态地在 In-Memory 列存储与其他内存组件之间进行弹性分配——当工作负载以分析查询为主时，IM 列存储可以自动扩展以容纳更多列对象；当交易负载增加、需要更多缓冲区缓存时，IM 列存储则可以自动收缩，将内存让给更紧迫的组件。 2.3 选择性 In-Memory 列与多级连接 选择性 In-Memory 列功能为 DBA 提供了一个更为便捷的语法：当只需要对表中部分列进行 In-Memory 填充时，可以使用 ALL 关键字来简化列列表的定义。多级连接和聚合功能则是对 In-Memory Vectorized Joins 的增强，进一步提升了复杂分析查询的向量化执行效率。 In-Memory Optimized Dates 利用 In-Memory 表达式框架，在 IM 列存储中预先提取日期的 MONTH 和 YEAR 部分，使得时间维度的比较查询实现极速响应。数据库内的 In-Memory Advisor 则提供了原生建议工具，帮助 DBA 更好地规划 In-Memory 列存储的使用策略。 总体来看，In-Memory […]

Oracle Database 23ai/26ai 新特性系列 —— 第五期：AI 时代的全面防护体系 在第四期中，我们聚焦于开发体验革命与空间数据能力的升级。如果说 AI 能力决定了数据库的上限，那么安全体系则决定了其下限——尤其在 AI 智能体、RAG 工作流和自然语言交互等新兴范式正在重构企业数据访问模式的当下，传统的安全模型正面临前所未有的挑战。 Oracle Database 23ai 和 26ai 在安全领域的投入远超常规版本迭代。从内核级的 SQL 防火墙到身份感知的深度数据安全，从抗量子加密到增强的区块链表，一个贯穿数据全生命周期、覆盖传统威胁与 AI 原生风险的安全体系正在形成。本期将系统解读这一安全体系的构建思路与核心特性。 一、SQL Firewall：数据库内核的智能防护 1.1 传统防护的盲区 在 Oracle Database 23ai/26ai 引入 SQL Firewall 之前，数据库安全的防线主要部署在网络层和访问控制层：网络防火墙用于过滤 IP 和端口，数据库层的权限系统用于控制用户对对象的访问。然而，这两种机制都无法有效应对一个日益严峻的威胁——SQL 注入攻击。攻击者利用应用代码中的漏洞，在合法数据库连接中注入恶意 SQL 语句，绕过应用层的访问控制，直接对数据库发起越权操作。 更棘手的是，传统的 Web 应用防火墙（WAF）和网络防火墙对加密流量无能为力，而现代应用几乎全部使用 TLS 加密。当 SQL 语句在加密通道中传输时，外部防火墙看到的只是一串无法解析的密文，无法识别其中是否隐藏着恶意代码。这一盲区正是 SQL 注入攻击最活跃的战场。 1.2 数据库内核级的 SQL 防火墙 SQL Firewall 是 Oracle Database 23ai 中作为 Oracle Database Vault 组件提供的新特性，从 26ai 开始深度集成到数据库内核中。其核心设计思想是在数据库引擎内部对所有传入的 SQL 语句进行实时检查和授权： SQL Firewall inspects all incoming SQL statements and ensures that only explicitly authorized SQL is run. SQL Firewall 拦截所有的数据库访问——无论 SQL 语句来自本地连接还是网络连接，无论传输是加密的还是明文的，均被统一检查。它检查的不仅仅是顶层 SQL，还包括存储过程中的 SQL 调用以及相关的数据库对象访问。 1.3 工作流程：学习、授权、阻断 SQL Firewall 的工作流程可概括为三个阶段： 学习阶段（Capture Phase） ：SQL Firewall 进入“学习模式”，捕获应用程序在正常运行时产生的所有 SQL 语句，记录到一个白名单允许列表（Allow-List）中。 授权阶段（Enforcement Phase） ：将学习阶段生成的允许列表应用到 SQL Firewall 策略中。管理员可以选择只记录违规 SQL 或直接阻断。 防护阶段（Protection Phase） ：SQL Firewall 进入“主动防护模式”，仅允许允许列表中的 SQL 语句执行，任何不在白名单中的 SQL 都会被实时阻断。 管理员还可以基于会话上下文（如 IP 地址、操作系统用户名、操作系统程序名）来限制数据库账户的连接方式，进一步降低凭据被盗或滥用的风险。 1.4 典型应用场景 SQL Firewall 最典型的应用场景是应用程序工作负载。在现代应用架构中，前端应用通过统一的服务账户连接数据库，所有用户的数据库操作均通过同一个数据库账户执行。传统的权限模型只能控制“哪个应用账户能访问哪些表”，无法区分“哪个最终用户在做什么操作”。SQL Firewall 通过白名单机制，将应用程序的业务逻辑固化为可执行的 SQL 模式——任何偏离业务逻辑的 SQL（包括注入攻击、异常查询）都将被实时阻断，无论攻击者是否已经获取了服务账户的密码。 1.5 26ai 的增强：白名单的精细化管理 从 26ai 开始，SQL Firewall 获得了更精细的管理能力。DBMS_SQL_FIREWALL PL/SQL 包新增了 APPEND_ALLOW_LIST_SINGLE_SQL 过程，允许管理员将单条特定的 SQL 记录从捕获日志或违规日志追加到现有的允许列表中。在之前的版本中，若要添加一条 SQL 到白名单，管理员必须将整个捕获日志全部追加，然后再手动删除不需要的条目——这一改进显著提升了白名单管理的灵活性和效率。 二、Deep Data Security：为 AI 智能体时代设计的细粒度授权 2.1 AI 智能体带来的安全挑战 SQL Firewall 解决了 SQL 注入这一经典威胁，但 AI 智能体时代带来了全新的安全挑战。当企业开始部署 AI 智能体来自动执行数据分析、报告生成、业务流程等任务时，传统的访问控制模型开始失效： 动态生成的 SQL：AI 智能体根据用户的自然语言提问动态构建 SQL 查询。这些 SQL 在开发阶段无法预见，因此无法像传统应用那样提前设置静态的白名单或权限。 高权限服务账户：AI 智能体通常通过高权限的服务账户连接数据库，以便代表不同用户执行多样化任务。但这也意味着一旦智能体被操纵或产生错误，可能导致大规模的数据泄露。 应用层访问控制的局限：传统的权限模型在应用层执行访问控制。当 AI 智能体动态生成 SQL 时，应用层无法预先审查每条 SQL 的安全性。 RAG 工作流的挑战：使用向量嵌入进行语义搜索的 RAG 工作流，同样难以通过应用层控制来确保安全。 “氛围编码”的安全隐患：AI 辅助的应用开发（即“vibe coding”）可能从训练数据集中复制不安全的授权模式，进一步加剧风险。 2.2 数据库原生的身份感知授权 Oracle Deep Data Security 是 Oracle AI Database […]

Oracle Database 23ai 新特性系列 —— 第四期：开发体验革命、空间数据与迈向 26ai 在前三期系列中，我们从 AI 向量搜索、JSON 关系二元性视图、数据库内机器学习、True Cache 以及全球分布式数据库等维度全面解读了 Oracle Database 23ai 的核心能力。如果说前三期聚焦的是 23ai“能做什么”——即数据库在 AI 时代的功能边界，那么本期我们将聚焦于 “谁来做”以及“如何做” ——即开发者如何以更低的门槛、更高的效率构建 AI 驱动的应用，以及 23ai 如何通过空间数据能力的重大升级打开全新的应用场景。 与此同时，随着 2025 年 10 月 Oracle 正式发布 Oracle AI Database 26ai（23.26.1 版本作为本地部署的第一版），23ai 与 26ai 之间的关系也需要厘清。因此，本期将在介绍 23ai 核心开发者特性之后，前瞻性地解读 26ai 的关键升级与演进路径。 一、开发体验革命：让 AI 数据库触手可及 Oracle Database 23ai 以“开发者优先”为核心理念，在开发体验层面实现了全方位的革新。从 JavaScript 存储过程到开发者角色，从 SQL 语法增强到数据使用域，23ai 正在将 Oracle 数据库从“DBA 的领地”转变为“开发者的乐园”。 1.1 JavaScript 存储过程与多语言引擎（MLE） Oracle Database 23ai 中引入的 Multilingual Engine（MLE） ，允许开发者在数据库中直接编写和执行 JavaScript 存储过程与函数。这项能力的底层基于 GraalVM——Oracle 的高性能多语言虚拟机技术，使得 JavaScript 代码能够与 PL/SQL 和 SQL 无缝互操作。 MLE 模块与调用规范 在 23ai 中，JavaScript 代码可以通过 MLE 模块（MLE Modules） 持久化存储在数据库中，成为一等数据库对象。开发者可以将复杂的 JavaScript 项目拆分为多个独立的模块，由团队成员并行开发，再通过 调用规范（Call Specifications） 将模块中的 JavaScript 函数暴露给 SQL 和 PL/SQL。这意味着，开发者可以在任何原本调用 PL/SQL 函数的地方直接调用 JavaScript 函数，两种语言之间的数据交换由数据库自动完成类型映射。 SODA API 与 JSON 原生支持 MLE 为 JavaScript 开发者提供了完整的 SODA（Simple Oracle Document Access）API 支持，允许开发者以 NoSQL 风格创建和查询 JSON 文档集合，无需学习 SQL。同时，23ai 中的 JSON 数据类型与 JavaScript 对象之间存在天然的映射关系，使得在数据库中处理 JSON 数据变得异常简便。 开发体验的持续优化 从 RU 23.9 开始，Oracle 进一步简化了 MLE 的入门体验：EXECUTE ON JAVASCRIPT 权限不再需要显式授予，开发者只需拥有 CREATE MLE 系统权限即可开始编写 JavaScript 代码。同时，23ai 引入了 编译时语法检查（Compile-Time Syntax Checking） ，在代码运行前即可发现语法错误。执行后调试（Post-Execution Debugging） 功能则允许开发者在程序运行完成后收集运行时状态信息，用于分析程序行为和定位缺陷，无需修改被观察的代码。 适用场景：MLE 让熟悉 JavaScript 的前端和全栈开发者可以无缝进入数据库端开发，利用 npm 生态中数以百万计的 JavaScript 库（如日期处理、数据验证、加密等）在数据库内核中运行，无需学习 PL/SQL 即可完成复杂的数据处理逻辑。 1.2 DB_DEVELOPER_ROLE：标准化开发者权限模型 在 23ai 之前，为数据库开发者分配权限通常的做法是授予 CONNECT 和 RESOURCE 两个角色。但这两个角色的设计已显陈旧——RESOURCE 角色的权限组合在不同版本中变化较大，且不包含对现代功能（如 MLE、Property Graph、Machine Learning 等）的访问支持。 23ai 引入的全新预定义角色 DB_DEVELOPER_ROLE ，代表了 Oracle 官方对“数据库开发者应该拥有哪些权限”的标准化定义。这一角色不仅整合了 CONNECT 和 RESOURCE 的核心功能，还囊括了创建多维数据集（CUBE）、机器学习模型、调度作业、动态执行 JavaScript（MLE）等高级功能的权限。 与传统的 RESOURCE 角色相比，DB_DEVELOPER_ROLE 的覆盖面和粒度更贴近现代开发需求，管理员可以快速为开发者分配设计、构建和部署应用程序所需的全部必要权限，大幅简化了开发环境的配置流程。 适用场景：当新开发者加入团队时，DBA 只需执行一条 GRANT DB_DEVELOPER_ROLE TO developer_name 命令，即可授予其完成应用开发所需的所有系统权限和对象权限，无需逐一配置。 1.3 […]