第四期：云原生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 […]

Oracle Database 23ai 新特性系列 —— 第三期：数据库内机器学习，让智能与数据共生 在数据库内机器学习（In-Database Machine Learning）这个方向上，Oracle 的布局早在 20 多年前就已经开始——从 Oracle 9i R2 首次提供内置数据挖掘功能，到如今已发展成为企业级数据科学和 AI 平台的核心支柱。而在 23ai 版本中，Oracle Machine Learning（以下简称 OML）迎来了一次质的飞跃，数据库内机器学习不再只是“能用”，而是向着“好用”和“智能”全面进化。 一、核心理念：让智能与数据共生 1.1 “零数据迁移”的 AI 范式 在传统的企业 AI 架构中，数据科学家通常需要将数据从生产数据库导出，经过复杂的 ETL 流程，导入到独立的机器学习平台或 Python 环境中进行模型训练和预测。这一过程伴随着几个难以解决的痛点： 数据时效性缺失：导出、转换、再导入的流程可能耗时数小时甚至数天，模型训练时使用的已是“过期数据” 安全风险与合规挑战：敏感业务数据一旦离开数据库环境，数据主权和审计追踪便难以保障 架构复杂与运维成本：多套系统之间需要维护数据同步、版本对齐和权限映射，系统复杂度呈指数级增长 Oracle Database 23ai 彻底改变了这一范式。OML 将 30 多种高性能机器学习算法直接内置于数据库内核，用户可以通过 SQL、Python、R 或低代码界面在数据所在的位置完成探索、准备、建模、评估和部署的全流程。正如 Oracle 所强调的：“AI where the data lives”——AI 能力的部署不再需要将数据从数据库中搬移，而是让智能能力在数据库内部落地。数据在哪，智能就在哪。 1.2 统一的数据科学平台 OML 超越了传统机器学习平台的边界，它不仅覆盖标准的结构化表数据，还能够分析事务数据、聚合数据、原始星型架构数据，甚至通过 Oracle Text 提取 CLOB 中的非结构化内容进行分析。更关键的是，OML 与数据库的安全体系深度集成——模型构建和评分过程遵循 Oracle 的权限方案，所有操作均被审计跟踪，这在金融、医疗、政府等强监管行业中具有不可替代的价值。 二、强大的数据库内算法库 2.1 超过 30 种原生算法 Oracle Database 23ai 提供了超过 30 种高性能、可并行化的数据库内机器学习算法，覆盖了企业级数据科学任务的主流需求。这些算法在数据库内核级别实现，利用 Oracle 底层 SQL 引擎的并行处理能力，能够处理 PB 级数据，同时保持对 SQL 标准的完全兼容。 核心算法涵盖以下类别： 分类：决策树、逻辑回归、朴素贝叶斯、SVM、随机森林、XGBoost、神经网络 回归：线性回归、多元线性回归、XGBoost（回归）、神经网络回归 聚类：K-Means、O-Cluster 关联规则：Apriori 特征提取：非负矩阵分解（NMF）、主成分分析（PCA） 异常检测：单类 SVM 时间序列：指数平滑方法（ESM） 2.2 23ai 新增算法：XGBoost、ESM 与 NMF 23ai 在算法库方面实现了显著扩充。其中最受关注的是 XGBoost 算法，它支持分类、回归和生存分析三类任务。XGBoost 作为一种基于梯度提升决策树的集成学习方法，在 Kaggle 等数据科学竞赛中长期占据统治地位，它以高精度、高效率和鲁棒性著称。XGBoost 的原生引入，使 OML 在模型精度上进一步逼近甚至超越 Python 生态的主流机器学习框架。 指数平滑方法（ESM） 是另一项重要补充，专为时间序列预测场景设计。相较于传统的 ARIMA 模型，ESM 对数据平滑性和趋势性变化更为敏感，适合处理带有季节性和趋势成分的业务数据（如销量预测、库存规划、流量预估）。 非负矩阵分解（NMF） 则专注于特征提取和降维，在处理高维稀疏数据（如文本挖掘、推荐系统）时具有独特的优势。 2.3 神经网络与随机森林的升级 在 23ai 中，神经网络和随机森林算法也得到了重构。新增的 ore.odmNN 类用于分类和回归任务，能够捕捉输入与输出之间复杂的非线性关系。ore.odmRF 类则以集成学习方式提供随机森林建模能力，替代了原有的 ore.randomForest。这些升级使模型的准确性和稳健性进一步提升。 2.4 数据库内评分的智能优化 OML 支持批量评分和实时评分两种模式。在生产环境中部署模型后，只需通过 SQL 查询调用预测算子即可完成评分，无需额外的部署流程。 值得特别强调的是，在 Exadata 和自治数据库上，OML 支持 Oracle Exadata Smart Scan 技术。评分处理可直接卸载到存储层执行，在数据存储端完成预测计算，显著减少了数据传输和 CPU 负载，带来了数量级的性能提升。 三、ONNX 集成：打破生态壁垒 3.1 ONNX：跨平台模型互操作的桥梁 Open Neural Network Exchange（ONNX） 是一种开源的深度学习模型表示格式，定义了统一的文件格式和算子集，使得模型可以在不同框架之间自由流转。23ai 的 OML 支持导入 ONNX 格式的机器学习模型，这意味着企业可以在任意环境（如 Hugging Face、PyTorch、TensorFlow、Scikit-learn）中训练模型，然后无缝导入到 Oracle 数据库中运行。 3.2 模型导入与应用 OML 支持导入以下类型的 ONNX 模型：文本嵌入模型（Transformer）、分类模型、回归模型和聚类模型。以 AI Vector Search 为例，企业可以通过 PL/SQL 包 DBMS_DATA_MINING 或 DBMS_VECTOR，将 Hugging Face 上的预训练文本嵌入模型以 ONNX 格式加载到数据库中，作为一等数据库对象供 AI Vector Search 使用。 在 OML4Py 中，Oracle 进一步简化了这一流程，提供了将 Hugging Face 模型自动转换为 ONNX 格式的工具。数据科学家无需关心底层转换细节，只需调用统一 API 即可完成从外部模型到数据库内部署的完整链路。 四、AutoML：让机器学习不再是数据科学家的专属 4.1 AutoML […]

Oracle Database 23ai 新特性系列 —— 第二期：数据库内机器学习、图技术与湖仓一体 在第一期中，我们重点介绍了 Oracle Database 23ai 的 AI 向量搜索、JSON 关系二元性视图等划时代技术。如果说 AI Vector Search 赋予了数据库“感知”和理解语义的能力，那么本期介绍的数据库内机器学习（In-Database ML）、图技术（Graph）与湖仓一体（Lakehouse）等特性，则赋予了数据库“思考”、分析和自主优化的能力。 Oracle 在机器学习领域的布局已有超过 20 年的历史——从 Oracle 9i R2 首次提供内置数据挖掘功能，到如今已发展成为企业级数据科学和 AI 平台的核心支柱。而在 23ai 版本中，Oracle Machine Learning（OML）迎来了一次质的飞跃，数据库内机器学习不再只是“能用”，而是向着“好用”和“智能”全面进化。 一、数据库内机器学习（In-Database Machine Learning） 1.1 核心理念：“零数据迁移”的 AI 范式 在传统的企业 AI 架构中，数据科学家通常需要将数据从生产数据库导出，经过复杂的 ETL 流程，导入到独立的机器学习平台或 Python 环境中进行模型训练和预测。这一过程伴随着几个难以解决的痛点： 数据时效性缺失：导出、转换、再导入的流程可能耗时数小时甚至数天，模型训练时使用的已是“过期数据” 安全风险与合规挑战：敏感业务数据一旦离开数据库环境，数据主权和审计追踪便难以保障 架构复杂与运维成本：多套系统之间需要维护数据同步、版本对齐和权限映射，系统复杂度呈指数级增长 Oracle Database 23ai 彻底改变了这一范式。OML 将 30 多种高性能机器学习算法直接内置于数据库内核，用户可以通过 SQL、Python、R 或低代码界面在数据所在的位置完成探索、准备、建模、评估和部署的全流程。正如 Oracle 所强调的：“AI where the data lives”——AI 能力的部署不再需要将数据从数据库中搬移，而是让智能能力在数据库内部落地。数据在哪，智能就在哪。 1.2 超过 30 种原生算法 Oracle Database 23ai 提供了超过 30 种高性能、可并行化的数据库内机器学习算法，覆盖了企业级数据科学任务的主流需求。这些算法在数据库内核级别实现，利用 Oracle 底层 SQL 引擎的并行处理能力，能够处理 PB 级数据，同时保持对 SQL 标准的完全兼容。 核心算法涵盖以下类别： 算法类别 包含算法 分类 决策树、逻辑回归、朴素贝叶斯、SVM、随机森林、XGBoost、神经网络 回归 线性回归、多元线性回归、XGBoost（回归）、神经网络回归 聚类 K-Means、O-Cluster 关联规则 Apriori 特征提取 非负矩阵分解（NMF）、主成分分析（PCA） 异常检测 单类 SVM 时间序列 指数平滑方法（ESM） 1.3 23ai 新增算法：XGBoost、ESM 与 NMF 23ai 在算法库方面实现了显著扩充。其中最受关注的是 XGBoost 算法，它支持分类、回归和生存分析三类任务。XGBoost 作为一种基于梯度提升决策树的集成学习方法，在 Kaggle 等数据科学竞赛中长期占据统治地位，它以高精度、高效率和鲁棒性著称。XGBoost 的原生引入，使 OML 在模型精度上进一步逼近甚至超越 Python 生态的主流机器学习框架。 指数平滑方法（ESM） 是另一项重要补充，专为时间序列预测场景设计。相较于传统的 ARIMA 模型，ESM 对数据平滑性和趋势性变化更为敏感，适合处理带有季节性和趋势成分的业务数据（如销量预测、库存规划、流量预估）。 非负矩阵分解（NMF） 则专注于特征提取和降维，在处理高维稀疏数据（如文本挖掘、推荐系统）时具有独特的优势。 1.4 数据库内评分的智能优化 OML 支持批量评分和实时评分两种模式。在生产环境中部署模型后，只需通过 SQL 查询调用预测算子即可完成评分，无需额外的部署流程。 值得特别强调的是，在 Exadata 和自治数据库上，OML 支持 Oracle Exadata Smart Scan 技术。评分处理可直接卸载到存储层执行，在数据存储端完成预测计算，显著减少了数据传输和 CPU 负载，带来了数量级的性能提升。 二、ONNX 集成：打破生态壁垒 2.1 ONNX：跨平台模型互操作的桥梁 Open Neural Network Exchange（ONNX） 是一种开源的深度学习模型表示格式，定义了统一的文件格式和算子集，使得模型可以在不同框架之间自由流转。23ai 的 OML 支持导入 ONNX 格式的机器学习模型，这意味着企业可以在任意环境（如 Hugging Face、PyTorch、TensorFlow、Scikit-learn）中训练模型，然后无缝导入到 Oracle 数据库中运行。 2.2 模型导入与应用 OML 支持导入以下类型的 ONNX 模型：文本嵌入模型（Transformer）、分类模型、回归模型和聚类模型。以 AI Vector Search 为例，企业可以通过 PL/SQL 包 DBMS_DATA_MINING 或 DBMS_VECTOR，将 Hugging Face 上的预训练文本嵌入模型以 ONNX 格式加载到数据库中，作为一等数据库对象供 AI Vector Search 使用。 在 OML4Py 中，Oracle 进一步简化了这一流程，提供了将 Hugging Face 模型自动转换为 ONNX 格式的工具。数据科学家无需关心底层转换细节，只需调用统一 API 即可完成从外部模型到数据库内部署的完整链路。 三、AutoML：让机器学习不再是数据科学家的专属 3.1 AutoML 用户界面 […]

Oracle Database 23ai 新特性系列 —— 第一期：AI 时代的融合数据库变革 引言 如果说数据库行业在过去十年经历了从“云优先”到“数据驱动”的演进，那么 2024 年 5 月 2 日，Oracle 宣布了一个足以标记行业分水岭的时刻——Oracle Database 23c 正式更名为 Oracle Database 23ai，作为全新的长期支持版本全面发布。版本号的更迭背后，承载的是超过 300 项新特性，其中近一半与人工智能直接相关。这不仅是 Oracle 历史上最大规模的 AI 化升级，更标志着这家年近 50 岁的数据库巨头正以彻底重塑的姿态，将数据库从“存储容器”转变为“能够自主思考和执行的智能平台”。 Oracle 执行副总裁 Juan Loaiza 直言：“Oracle Database 23ai 对全球企业而言改变了游戏规则。”从原计划的 23c 到正式发布的 23ai，Oracle 用一次看似简单的命名调整，完成了数据库行业数年的 AI 转型路线图。Premier Support 将持续至 2031 年 12 月 31 日，这意味着 23ai 将成为未来近十年企业数据架构的核心基石。 本系列将分多期全面解读 Oracle Database 23ai 的核心新特性。作为开篇之作，本期将聚焦于 23ai 的版本定位、AI 向量搜索、JSON 关系二元性视图以及多租户与安全增强等重磅特性。 一、版本定位：为什么是“23ai”？ 1.1 从 23c 到 23ai 的战略转型 Oracle Database 23c 最初于 2022 年 Oracle 年度大会上首次亮相，并于 2023 年初率先面向开发者发布，这是 Oracle 首次在向企业正式发布之前先行面向开发者群体开放——这一策略转变，意在拥抱开发者生态，为数据库业务注入新的增长动力。2023 年 9 月，Oracle 宣布在 23c 中增加向量搜索能力；2024 年 5 月，随着 AI 功能的全面成熟，Oracle 正式将 23c 更名为 23ai 并推向市场。 从“c”（Cloud）到“ai”，品牌标识的变更折射出 Oracle 核心战略的转变：云能力仍是基础，但 AI 能力已成为牵引企业数字化变革的核心引擎。Oracle 数据库不再只是一个事务处理与数据存储的平台，而是原生支持 AI 工作负载的融合数据平台。 1.2 版本发布节奏与可用性 Oracle Database 23ai 在 2024 年 5 月率先在 Oracle Cloud Infrastructure（OCI）、Oracle Exadata Database Service 以及 Oracle Database@Azure 上以云服务形式提供。随后在 2024 年 7 月，23ai 正式登陆 Oracle Database Appliance（ODA），将 AI 能力引入一体化设备平台。对于本地部署（On-Premises）用户，经过多次版本迭代后，Oracle 于 2026 年 1 月 28 日正式发布 23.26.1 版本，标志着 23ai 可在通用 Linux x86-64 平台本地部署，标准支持持续至 2031 年底。 值得一提的是，Oracle 在 2026 年 3 月伦敦 AI World Tour 上进一步宣布，23ai 通过应用 RU 23.26.0 即可无缝升级为 Oracle AI Database 26ai，无需数据库升级或应用重认证——这表明 Oracle 的 AI 数据库产品线已进入持续迭代的快车道。 二、AI Vector Search：将语义搜索内建于数据库核心 如果说 23ai 只能介绍一个特性，那一定是 AI Vector Search。这是本次发布最具标志性的创新，也是 Oracle 将数据库从“关系引擎”进化为“AI 引擎”的核心能力。 2.1 VECTOR 数据类型 AI Vector Search 的基础是全新的 VECTOR 数据类型。它是一个同构数组，支持 8 位有符号整数、8 位无符号整数、32 位浮点数或 64 […]