-
NineData 月度版本更新，数据复制与对比新增 149 种复制链路、149 种对比链路
NineData 扩展了数据库 DevOps 的数据源与 SQL 开发能力，更新了数据资产、权限和审批管理，并补充 ChatDBA 知识库与会话能力。数据复制新增 Debezium 数据格式、增量 DDL 和数据源配置联动更新；数据对比也修复了 Oracle 长字段和 Redis Stream 的结果问题。
-
“氛围编程”与数据库工程的结合：清理AI生成的SQL
AI生成的SQL语句看似完全合理，却可能暗藏细微的性能问题。编码助手可能会构建不必要的复杂查询，在已建索引的列上使用阻碍高效访问的函数，生成冗余的子查询，或者未能充分利用现有的索引。
-
数据库 DevOps 工具怎么选？迁移复制与变更管理方案对比
本文从数据库 DevOps 管理与数据迁移复制两个维度，对 NineData、Bytebase、Liquibase、Flyway、OceanBase OMS 和云厂商 DTS 进行对比，分析各方案的能力边界、OceanBase 适配情况及组合使用方法，为数据库变更治理、全量迁移和实时同步提供选型参考。
-
Oracle 到 OceanBase 迁移实施方案：对象转换和增量同步实践
本文介绍 NineData 在 Oracle 到 OceanBase Oracle 模式迁移中的完整方案，涵盖结构复制、对象转换、全量迁移、DML/DDL 增量同步、数据校验和低停机切换，重点说明主键约束、Oracle 日志准备、异构兼容性验证和回退方案。
-
数据库安全防护体系构建要点
数据库承载着企业最核心的资产——业务数据、用户信息、交易记录与经营指标。一旦发生泄露、篡改或不可用，影响往往不止于技术层面，还会波及合规、声誉与业务连续性。构建一套完整的数据库安全防护体系，目标不是堆砌安全产品，而是围绕"数据"这一核心对象，建立可落地、可审计、可持续演进的防护能力。 一、先明确防护对象与边界 在动手部署任何工具之前，需要先回答几个基础问题： 有哪些数据库：关系型、NoSQL、缓存、数据仓库、对象存储中的结构化数据等，是否都纳入了管理视野。 数据分布在哪里：自建机房、私有云、公有云、混合云，是否存在影子数据库和未登记的实例。 谁在访问数据：应用账号、运维账号、开发测试账号、第三方接口、数据分析人员。 数据有多敏感：哪些是个人身份信息、支付信息、商业机密，需要分级分类。 资产不清、边界不明，后续的
-
当 AI Agent 开始执行 SQL，企业该如何守住数据库安全底线
AI Agent 开始执行 SQL 后，企业如何防止越权读取、误删数据和高风险 SQL 直接落库？本文从 AccessKey、细粒度权限、读写分离、SQL 规则预审、人工审批和审计溯源六个方面，结合 NineData Skill/OpenAPI 场景给出数据库安全底线与上线检查表。
-
Agent 时代，数据库要“重做”吗？
Agent 时代，数据库为什么要 “重做”🤔？ 对话阿里云专家解读湖库一体新架构💡。
-
做好数据库一体机的关键是什么？
数据库一体机并不是“数据库 + 服务器 + 存储”的简单拼装。它更像是一套围绕数据库负载重新设计的系统工程。做好数据库一体机的关键，不在于堆叠硬件参数，而在于能否把软硬件协同、性能确定性、运维体验和场景适配做成一个整体。 一、先明确：数据库一体机到底解决什么问题 数据库一体机通常面向对性能、稳定性和交付效率有较高要求的场景。它的价值主张一般包括： 开箱即用：软硬件预集成、预调优，缩短部署周期。 性能可预期：针对数据库负载做端到端优化，而不是依赖用户自行调参。 运维简化：统一监控、统一升级、统一故障定位。 责任边界清晰：由一体机厂商对整体方案负责，减少多厂商协同成本。 因此，做好数据库一体机的第一关键，是从“卖盒子”转向“交付一套可稳定运行的数据库系统”。 二、关键一：软硬件协同设计能力 数据库对 I/O、内存、
-
AI 时代数据库会退化为存储容器吗？
当 LLM 开始接管越来越多的查询理解、数据编排与结果生成环节，一个尖锐的问题被反复抛出——数据库会不会被"降级"为单纯的存储容器？这个问题目前没有定论，但可以从数据库的核心职责、AI 系统的实际依赖关系两个方向做一次理性拆解。 一、问题的由来 随着 LLM 与各类 AI Agent 在应用层快速铺开，数据访问的链路正在发生变化： 过去，用户或应用需要自己写 SQL、理解表结构、处理 JOIN 与聚合； 现在，越来越多的自然语言请求由模型翻译成查询意图，再由模型或 Agent 决定调用哪个数据源、如何拼接结果。 在这种叙事下，一种观点认为：数据库正在被"管道化"——它只负责把数据存好、取出来，而"理解数据、组织数据、解释数据"的智能环节被上移到了模型层。于是就有了"数据库退化为存储容器"的说法。 二、数据库不只
-
为什么数据库厂商要组建 FDE 工程师？
FDE（Forward Deployed Engineer，前线部署工程师）正在从数据智能公司的“特有种”变成数据库厂商的“标配岗位”。这背后不是一次简单的招聘动作，而是数据库行业交付模式、客户结构和产品竞争逻辑同时发生变化的结果。 一、先厘清：FDE 到底是什么角色 FDE 这个概念最早被广泛认知，来自 Palantir 等数据智能公司。它的核心特征不是“驻场开发”，而是把工程能力直接推到客户现场： 既懂产品底层能力，也懂客户业务场景； 不只是答疑和排障，而是能写代码、搭方案、做集成； 是产品团队伸到客户侧的“触角”，把现场问题反向带回研发。 换句话说，FDE 是工程师，不是售后；是方案落地者，不是销售支持。理解这一点，才能理解数据库厂商为什么开始需要它。 二、数据库的交付难题，正在从“卖 License”变
-
数据库离自治还有多远？
过去几年，“自治数据库”“自动驾驶式数据库”成为数据库领域的高频词。厂商描绘的愿景很清晰：系统能够自我监控、自我调优、自我修复、自我安全防护，把 DBA 从重复劳动中解放出来。但从现实落地看，数据库距离真正的“自治”仍有相当距离。本文尝试从能力分层、技术瓶颈和演进路径三个角度，讨论这个问题。 一、“自治”到底指什么？ 在讨论距离之前，需要先界定概念。业界所说的数据库自治，通常包含几个递进层次： 自动化（Automation）：按预设规则执行任务，例如自动备份、自动扩容、定时巡检。 自适应（Adaptive）：系统能根据负载和运行状态动态调整参数或资源分配。 自治（Autonomous）：系统能自主感知问题、自主决策、自主执行并验证效果，尽量减少人工介入。 自愈与自优化（Self-healing / Self-t
-
NineData亮相2026新加坡Tech Week，以数据管理AI Agent加速布局全球市场
9月29日至30日，新加坡科技周（Tech Week Singapore 2026）在新加坡滨海湾金沙会展中心举办。在浙江省商务厅的组织邀请下，NineData作为浙江参展企业代表亮相本次展会，面向亚太及全球客户、合作伙伴与行业观众，展示新一代云原生智能数据管理平台的核心能力。
-
没有权限，AI Agent 也读不到数据：NineData 数据库安全管控实测
AI Agent 没有权限还能读取数据库吗？本文通过查询、新增和 DELETE 三条实际操作链路，验证 NineData 如何使用 AccessKey、细粒度权限、SQL 规则、人工审批和审计控制 Agent 的数据库访问，并分析直连旁路、提示注入、规则绕过与凭证泄露等安全边界。
-
9月数据库圈值得关注的事 | 2026
9月，中国信息安全测评中心与国家保密科技测评中心联合发布《安全可靠测评结果公告(2026 年第 3 号)》。数据库品类新增三款集中式产品通过测评;星环科技正式登陆港交所主板挂牌上市;Omdia发布《2026年亚太及大洋洲分布式数据库市场研究》，2025年亚洲及大洋洲分布式数据库市场规模达到9亿美元，预计2026年将增长至11亿美元，到2029年进一步达到18亿美元……
-
抖音电商数据采集实践：精选联盟商家信息与联系方式采集工具简析
在抖音电商生态中，精选联盟是连接商家与达人、撮合CPS带货合作的核心载体，平台沉淀了海量细分品类的优质商家资源。对于电商数据研究、行业竞品分析、电商生态技术调研等场景而言，批量、合规化获取精选联盟商家公开信息，是数据挖掘与行业分析的基础环节。常规人工检索、手动复制的采集方式，存在效率低、数据零散、重复度高、遗漏量大等问题，无法适配大批量数据统计需求。基于Python爬虫技术与网页解析逻辑开发的抖音
-
胖头鱼的技术专栏-473 改JSON的一个字段不再重写整篇：我给PostgreSQL 18写了个扩展
项目地址：https://github.com/Haiwen-Yin/pg_splitjson ，Apache 2.0，PG18 可编译，欢迎提 issue。
-
胖头鱼的技术专栏-471 数据库优化的三层楼——为什么多数人总在第二层打转
数据库优化的三层楼
-
为什么有的业务倾向使用数据库一体机？
如今，数据库一体机（Database Appliance）依然在金融、电信、政务等关键行业占据一席之地。它并非"过时产物"，而是在特定业务场景下被反复验证过的工程选择。 一、什么是数据库一体机 数据库一体机通常指将数据库软件与经过预集成、预调优的服务器、存储、网络等硬件打包交付的一体化系统。厂商在出厂前完成软硬件适配与性能调优，用户拿到的是"开箱即用"的整体方案，而非需要自行拼装的软硬件组合。 二、业务为什么倾向选择一体机 1. 交付确定性高，上线周期短 传统自建数据库需要经历选型、采购、上架、系统安装、参数调优、兼容性验证等一长串环节，任何一环出问题都可能拖慢整体进度。一体机把这些工作前置到厂商侧完成，业务方更多是"到货即部署"，对有时间窗口压力的核心系统上线尤为友好。 2. 软硬件协同调优，性能表现可预期
-
Agentic AI 时代，数据库的数据分支能力为何如此重要？
当 AI Agent 从“回答问题”走向“自主执行任务”，数据库的角色正在被重新定义。数据分支正在成为 Agentic AI 时代数据基础设施的关键拼图。本文基于现有公开技术逻辑进行推演，不涉及具体产品版本与实测数据。 一、从 Copilot 到 Agent：数据库面临的新压力 过去两年，AI 与数据库的结合主要集中在“辅助查询”层面：自然语言转 SQL、查询优化建议、结果解释。这类场景中，AI 是只读的旁观者。 而 Agentic AI 的核心变化在于：Agent 会自主地读、写、试错、回滚、再执行。它不再只是生成一段 SQL 交给人类确认，而是可能直接：创建临时表做数据探索，批量修改生产数据以完成某个业务目标，在多个假设之间反复试验，调用多个工具链，形成长事务式的操作序列。 这带来一个根本矛盾：Agent
-
数据库的智能化发展：从 AI4DB 到 DB4AI
数据库与人工智能正在双向奔赴。一方面，AI 技术被引入数据库内核，用于优化器、索引、参数调优与运维自治，这被称为 AI4DB；另一方面，数据库开始承担 AI 工作负载，为模型训练、特征工程与推理提供数据底座，这被称为 DB4AI。 AI4DB：用 AI 改造数据库 AI4DB 的核心思路，是把AI引入数据库自身的管理与执行过程。依据现有技术方向，主要可以归纳为以下几类： 1. 智能查询优化 传统优化器依赖代价模型和统计信息，在复杂查询或数据分布倾斜时容易估算偏差。AI4DB 尝试用学习型优化器替代或增强代价模型，例如： 学习型代价估计：用模型预测算子代价与基数。 学习型计划选择：根据历史执行反馈选择更优计划。 端到端优化：减少对人工规则的依赖。 2. 智能索引与存储 索引推荐、自动索引、学习型索引是常见方向。学
