AlloyDB 的托管远程 MCP 服务器正式可用
Google Cloud 把 AlloyDB 的 MCP 接入做成全托管服务,结束预览进入正式发布。
保留原始来源与发布日期的新闻、博客和活动。
Google Cloud 把 AlloyDB 的 MCP 接入做成全托管服务,结束预览进入正式发布。
微软把这套 Postgres 工作流带进 Cursor 编辑器,连接、查询和管理都可以留在编辑器里。
Mihail Nikalayeu 提醒这个问题可能让大量重整工作白做,压力测试套件还在开发。
Chao Li 报告问题并给出补丁,Fujii Masao 审阅后推入代码库。
多重继承下子表不跟着父表改状态,v7 补丁递归检查本次操作之外是否还有强制父表。
日志与 SQL 视图两条路线并行,先合入日志补丁,视图列出后端、预备事务和复制槽的贡献。
Ammar Askar 公布了一个概念验证:经由 github.dev 与 VS Code webview 相关的链路,用户点一次链接就可能被窃走 GitHub token。利用面把 webview、快捷键与命令面板、扩展安装和 token 暴露串在一起。开发者 token 能读写私有仓库,一键失窃的影响远大于普通 XSS。团队可以限制 github.dev 的使用、清理站点数据并降低 token 权限。
Google 把图算法以预览形式放进 Spanner Graph。Spanner 本来就有全球一致性和 SQL/GQL,图遍历和图算法进到库内之后,把数据 ETL 到外部图分析系统的必要性下降。这说明图能力正从独立图数据库的专属卖点,变成多模型云数据库和事务数据库的常规配置。选型仍要看数据规模、一致性要求、查询语言、算法库是否够用、ETL 代价和云锁定;PostgreSQL 一侧对应的方向是 SQL/PGQ 与 Apache AGE。
Redis 8.8 不是普通补丁版:新增原生 Array 数据结构和 INCREX 命令,改进了 Streams 待处理消息的释放,Search 与 Query 侧做了性能优化和 profiling,HyperLogLog、MGET、MSET、HGETALL 等高频路径也继续提速。方向上 Redis 8.x 一直在从缓存走向多模型内存数据平台,搜索、向量、时序、限流和流处理这些能力被反复加强。
AWS 数据库博客给出一套用 Debezium 做实时变更数据捕获的做法,替代延迟较高的批量 ETL。组件是打开逻辑复制的 Aurora PostgreSQL 或 RDS for PostgreSQL、跑在 MSK Connect 上的 Debezium 连接器,以及做消息流的 Amazon MSK;Debezium 直接读预写日志,把变更推成 Kafka 主题。步骤包括建参数组打开逻辑复制、配 IAM 角色和上传自定义插件。
微软在 TechCommunity 上继续推 Azure HorizonDB,定位是面向 AI 时代的企业级 Postgres,路线是存算分离、内置向量与 AI 能力、企业安全默认打开。要留意 Postgres 兼容和 PostgreSQL 扩展生态完全兼容不是一回事:评估这类产品得看扩展支持范围、复制与备份方式、迁移路径、锁定风险,以及真实基准和价格模型。
ClickHouse 把自家的托管 Postgres 推进 beta,卖点是本地 NVMe 存储、到 ClickHouse 的原生 CDC 和 pg_clickhouse 扩展,主张用 Postgres 存事务状态、ClickHouse 做实时分析,省掉两边之间的外部管道和胶水代码。这意味着 OLAP 厂商不再只做 Postgres 数据接入,而是直接承接 OLTP 托管。自建方案的差异点仍在控制权、扩展生态和成本透明度。
PostgreSQL 19 实现了 ISO/IEC 9075-16 的 SQL/PGQ,可以直接查询存在关系表里的图数据。Cybertec 的教程用 person 和 knows 两张表演示:先用 CREATE PROPERTY GRAPH 声明点表、边表和两者的关系,再用 GRAPH_TABLE 写模式匹配,多跳可以查朋友的朋友。既不用复制数据,也不用装扩展,底层由 PostgreSQL 重写成普通的连接操作。
PostgreSQL 19 Beta 1 的发布公告正在邮件列表上打磨,Jonathan Katz 逐条收集功能描述和措辞意见。Florents Tselai 建议补上 GROUP BY ALL,并改写 jsonpath 字符串函数一节,两条都被采纳:公告会说明 GROUP BY ALL 把非聚合、非窗口的输出列自动并入分组。Tom Lane 建议把 parameters 改成输出列,以免和函数参数混淆。
Tatsuo Ishii 与 Jian He 支持在 0xF0 边界预留 16 个控制码,为将来扩展留出空间。
PG19 只放开发布名重复,订阅名会被复用作槽名,留到下个版本再处理。
Peter Smith 主张 conflict_log_destination 用逗号分隔字符串,Amit Kapila 认为枚举加 all 更省事。
pg_get_publication_tables() 会返回被排除的表,CURRENT_SCHEMA 下的跨模式排除也缺校验。
云账单之外还有一笔隐性成本:工程师花在数据库维护上的重复时间。文章称之为日程债务,在高负载 PostgreSQL 场景里表现为分区管理、autovacuum 调优、复制监控和容量规划,作者估计可以占掉资深工程师两到三成的时间,而且数据从百万行长到十亿行之后,运维手册变厚、新人上手变慢、产品迭代跟着变慢。建议先做一次 90 天日程审计,统计与数据库相关的故障、会议和维护,再用自动分区、保留策略和存储优化把生命周期管理从人手里拿走。
Radim Marek 提醒 pg_stat_statements 不是查询仓库,而是共享内存里一张定长哈希表。由此有几处坑:queryid 按对象 OID 计算,跨大版本或重建表之后就会变,不能当持久主键;ORM 的别名、列表和 LIMIT 差异会把一条逻辑查询打散成上百行;条目数受 pg_stat_statements.max 限制,被淘汰的历史直接消失;mean_exec_time 是开机以来的平均,看不出 p99 毛刺。