标签

数据库

用 Microsoft Fabric 和 Azure 数据库搭建 Agentic 应用:统一数据与 AI 的实战路径

来源: azure.microsoft.com 39
Agentic 应用正在从"问大模型一个问题"进化到"让 AI 自主规划、调用工具、读写数据并完成多步任务"。但 Agent 要真正可靠地运转,离不开一个能同时支撑分析推理和实时操作的数据底座。Microsoft Build 2026 把这个底座的名字说得很清楚——Microsoft Fabric + Microsoft Databases,一个统一的...

Azure Database for PostgreSQL Flexible Server:同步复制 standby 置入提交路径意味着什么

来源: postgr.es 45
大多数托管 PostgreSQL 服务商把 standby 复制做成"尽力而为"——写主库成功就返回客户端,standby 在后台异步追赶。Azure Database for PostgreSQL Flexible Server 走了一条不同的路:standby 直接参与提交路径,每一次写操作都要等同步复制到第二台服务器确认后才向客户端返回成功。 这...

DeepChat → DeepWork:从聊天工具到数字员工的技术重构

来源: oschina.net 35
从 OpenClaw 到各类 AI 热潮,企业对"数字员工"的期待已经从"能对话"升级为"能干活"。DeepChat 这次更名为 DeepWork,不只是换了个名字——底层框架、向量存储、RAG 架构全部重写,是一次真正意义上的技术重构。 这次更新最硬的改动是把 AI 框架换成了 Spring AI + Spring AI Alibaba。之前 Dee...

半夜表膨胀四倍:PostgreSQL 逻辑复制遇上 statement_timeout 的灾难现场

来源: postgr.es 29
一次看起来万无一失的 PostgreSQL 迁移,在午夜把人吓醒——源端表安安静静几十 GB,目标端同样几张表却膨胀到 400 GB 以上,还在继续涨。排查到最后,罪魁祸首是一个再正常不过的配置:。两个各自合理的机制撞在一起,就制造了一场无声的灾难。 客户要把一个 PostgreSQL 数据库通过逻辑复制迁移到新服务器。逻辑复制的第一步是初始表拷贝——...

PostgreSQL 的 now() 在事务里是"冻结"的——你踩过这个坑吗?

来源: oschina.net 47
是 PostgreSQL 里最常被随手调用的函数之一,取当前时间、写日志、算过期……几乎无处不在。但如果你在事务里用它,它返回的并不是"此刻",而是事务开始的那一刻。一个跑了两分钟的事务,从头到尾每次 拿到的都是同一个时间戳。这个行为符合 SQL 标准,却和大多数人的直觉相悖,最近 Emmett 库的作者 Marcin 就因此踩了一个实打实的 bug。...

CloudDM 3.1.0:开源数据库管控工具的部署与升级体验重构

来源: oschina.net 38
研发和 DBA 日常常被各种数据库客户端割裂:权限靠人肉流转,SQL 审核凭口头约定,数据脱敏更是形同虚设。CloudDM 作为一款面向团队的开源数据库管理工具,把统一 Web 访问、权限控制、SQL 审核、数据脱敏和数据库 CI/CD 捏合到了一个平台上。3.1.0 版本没有堆砌新概念,而是把刀挥向了最影响落地效率的环节——首次部署初始化、驱动下载与...

PostgreSQL leakproof 函数:行级安全与性能之间的那条线

来源: postgr.es 42
行级安全(Row-Level Security)是 PostgreSQL 提供给多租户场景的一把利器——在数据库层面直接隔离不同租户的数据,省去应用层反复过滤的麻烦。但很多团队真正用上 RLS 后,第一个撞上的墙不是安全,而是性能。查询慢得离谱,索引仿佛失效,原因指向一个不起眼的函数属性:。Laurenz Albe 的这篇文章把这个问题拆得很透,也提出...

Next.js v16.2.7:修掉了开发缓存失效和 Playwright 测试卡死的问题

来源: oschina.net 35
Next.js v16.2.7 是一个纯 backport 修复版本,没有新功能,只把 Canary 分支里已经验证过的几个 bug 修到了稳定线。如果你在 v16.2.x 上遇到过开发模式下缓存加载报错、或者 Playwright 测试莫名卡住,这个版本直接解决这些问题。 这个 bug 的表现:在 下,某些通过浏览器 HTTP 缓存返回的页面会触发缓...

PostgreSQL 三个代价常量:为什么你几乎永远不该改它们

来源: postgr.es 36
PostgreSQL 的查询规划器靠一组常量给每条执行路径"打分",最终选出成本最低的那个方案。其中 、 和 是最常被提及的三个。但最实用的一条建议是——你几乎永远不该修改它们。下面解释原因,以及在真正需要调优时该做什么。 规划器的成本模型把每条路径的代价拆成两部分:I/O 代价(读磁盘页)和 CPU 代价(处理一行、比较一个值)。三个常量负责后者: ...