数据库行业全景

数据库行业由多种工作负载共同构成。 订单扣库存、扫描十亿行报表、保存传感器读数、召回相似文档，对延迟、吞吐、一致性和成本的要求不同。一家公司同时使用三四种系统完全合理；每多一套系统，也会增加数据同步、权限和恢复工作。

SQL 已跨越传统关系型数据库。 PostgreSQL、MySQL、DuckDB、Snowflake、ClickHouse、Trino 都提供 SQL，但接口相似并不意味着事务、存储、部署和计费方式相同。分类时应同时看工作负载、数据模型和部署形态。^{[6][8][9][12][27][88]}

商业收入与开发者影响力分布在不同地方。 免费引擎可以被大量使用，商业价值却由云服务、企业支持、数据治理和周边平台获取。开发者调查显示 Postgres 使用广泛；云数仓平台则可以用较少的开发者覆盖大量企业支出。不能根据问卷中的 Snowflake 使用率比 MySQL 低，就判断其商业市场只有后者的十分之一。^[3][34]

通用平台扩展能力，专用系统继续争取高要求场景。 PostgreSQL 可通过扩展处理空间与向量，Elasticsearch 同时做全文、向量及混合检索。专用系统的采购理由需要落到具体负载下的召回质量、延迟、吞吐、资源隔离或运维效率。^{[22][23][46][49]}

未来的竞争会涉及数据所在的位置、访问权限和应用开发入口。 开放表格式提供跨引擎共享数据的基础；Databricks Lakebase 与 Snowflake Postgres 则说明分析平台正进入事务应用。本报告据此推断：目录、治理、开发者工作流与迁移能力的价值可能上升。它们是有证据支持的方向判断，还不能折算成确定的未来份额。^{[25][28][65][66]}

市场数据保留各自的观察年份。技术文档核查到 2026 年 9 月 19 日；公开统计没有相同的更新速度。本文没有获得完整的全球 2025 年厂商收入份额表，也没有把尚未实现的预测填进历史数据。性能比较属于选型分析，本次没有对所有产品进行实际压测。

坐标一：系统每天主要做什么？

坐标二：数据与访问路径如何组织？

关系模型以表、关系和约束组织业务；文档模型把经常一起访问的嵌套字段放在一起；键值系统围绕 key 访问；宽列系统围绕分区键、列族或聚簇组织大规模记录；图模型把关系作为可遍历对象。时序侧重时间、设备和标签，向量侧重距离或相似度，空间模型则包含坐标、几何和拓扑关系。一个产品可以支持多个模型。^{[6][16][17][23][24][49][58]}

宽列与分析型列存是两个概念。 Cassandra/Bigtable 的宽列数据模型围绕分区键读取业务记录；ClickHouse 等分析引擎按列组织数据以减少扫描与解码。名字都有“列”，并不能推出它们擅长相同查询。^[12][16][58]

坐标三：谁运行它，数据放在哪里？

同一个 Postgres 可以自建、托管、运行在独立虚拟机上，也可以被包装成带分支与按需计算的平台。嵌入式引擎与应用共享进程；客户端/服务器数据库通过网络提供服务；湖仓把数据文件、目录和计算拆成不同层。部署形态会直接影响故障域、账单和人员投入。^{[9][11][25][65][66]}

上表是机制层面的工程概括，并非各产品的性能排名。存储引擎还会组合多种机制，内存数据库也可能持久化，列式数据库也可能支持更新。有关 B-tree 与 LSM 的进一步原理，可参阅本站的存储结构专题。

三种常见数据回答的是三个不同问题

DB-Engines 明确将其榜单定义为流行度排名。本次原站访问不稳定，因此不转录具体月榜分数，保留方法链接作为补充观察入口。魔力象限的“领导者”位置也不是收入占比。^[5]

可公开核实的全球总量

Gartner 对 2024 年全球 DBMS 市场的公开摘要给出：规模 1,197 亿美元，同比增长 13.4%；云端占 64%，本地部署占 36%。这对应该机构的数据库管理系统收入统计范围，不包括一切泛数据基础设施支出。非关系型与关系型细分增长分别为 22.7% 和 10.8%。^[1]

2025 年份额报告已于 2026 年 5 月发布，但本次取得的公开摘要没有完整金额与厂商占比表。因此，1,197 亿美元在此作为可核验的 2024 年历史基准，不冒充 2025 年或 2026 年规模。^[2]

Gartner 的另一份预测摘要预计 2026 年 DBMS 市场为 1,610 亿美元、增长 18.4%。这是一份预测，不是截至本次核查日已经确认的全年结果；也不据此倒推出每个厂商的收入。^[72]

一张真正可比较的使用率表

这组数据表明，在这批问卷回答者中，PostgreSQL 与 MySQL 都有广泛使用；SQLite 和 Redis 也占据重要位置。DuckDB 的 3.3%、Snowflake 的 4.1% 与 ClickHouse 的 2.4% 对应不同用户和工作负载，不适合作为三者可服务市场规模的比例。问卷的自选择、职业构成、地区和多选方式都会影响结果。^[3][86]

公司规模：可以展示，不应直接换算为份额

这里选用完整财年或明确时点的样本以解释商业规模，未把该表标为最新季度排名。Snowflake 与 MongoDB 在财年结束后还会继续披露季度变化。

一个有完整百分比的细分市场样本

下表来自腾讯云公开转载的 IDC 图表，原图标明统计对象为 2023 年中国金融行业分布式事务型数据库市场，规模 2.23 亿美元。本次核对了 PDF 第 5 页原图；采用历史样本是为了给出有明确分母的真实份额，不能拿它代表今天的中国数据库整体市场。^[87]

数据原作者为 IDC，公开载体是参与市场竞争的腾讯云，存在选择性展示可能。本文使用统计事实并注明载体，没有复制原图。若用于采购或市场预算，应取得更新且同口径的原始完整报告。

哪些份额目前不能诚实地填出？

本次公开资料不足以给出同一年度的全球厂商收入份额全表，也不足以分别列出向量、时序、图、嵌入式数据库中所有产品的可信收入百分比。它们还面临免费部署多、云平台不拆分收入、一个产品横跨多个类别的问题。因此，缺数据的格子保持缺数据；可以用使用率、产品覆盖和客户结构辅助理解竞争，不能将代理指标改名为市占率。

订单涉及客户、商品、支付、库存与退款，许多状态需要在同一事务中满足约束。关系数据库把部分正确性责任放进数据库：主键、唯一性、外键、检查约束、事务隔离与恢复机制共同发挥作用。事务“成功”后的持久性仍取决于日志、复制与配置，不能只看到 ACID 四个字就省略故障验证。^[6][88]

MySQL 与 PostgreSQL 如何比较？

对于熟悉 MySQL、已有成熟应用与运维体系的团队，保留 MySQL 往往比为了流行趋势而迁移更划算。若新系统需要复杂 SQL、丰富类型、JSONB、空间或向量扩展，Postgres 值得优先验证。这个判断来自能力与需求匹配，并非对所有工作负载的速度结论。两者都能支撑重要业务，瓶颈也都可能来自索引、连接管理、事务长度或应用访问方式。^{[6][46][49][88]}

例如，同一笔订单在应用里先查库存、再发两条独立更新，可能存在并发竞态；更换数据库品牌未必修复逻辑。应先明确操作是否必须原子、失败能否重试、重试是否幂等，再选择事务范围和隔离级别。

托管数据库卖的是什么？

托管服务把部署、备份、故障切换、补丁等工作的一部分产品化。用户仍负责 schema、查询、容量、权限以及业务恢复验收。Amazon RDS 是服务家族，Aurora 是其中具有自身存储架构的数据库产品；“用了 RDS”并不能回答用了 MySQL 还是 PostgreSQL，也不能单列成与两者互斥的引擎份额。^[61]

SQLite 可用于真实生产业务，但它属于不同的部署与并发路线，后文单列。选择通用关系数据库作为初始主库的工程优势，是能先用较少组件验证业务，再根据实测瓶颈增加专用能力。

传统应用常通过分库分表扩大容量：按用户或租户拆分数据，应用或中间件负责路由。分布式 SQL 希望让查询、分片和复制更统一，并在多个节点上提供事务。Vitess 则代表保留 MySQL 引擎、通过集群层处理分片的另一条路线。^{[13][14][55][56][57]}

强一致性有物理成本

一笔事务若必须等待跨区域副本确认，就要承担相应网络往返和协调。增加节点也无法让一个极热的账户行无限并发更新。架构评估至少应回答：写入在哪个区域确认，读取能否陈旧，区域断开时哪些操作继续，业务键是否集中到同一分片。Spanner 的外部一致性是明确的语义能力，不等于所有跨洲请求都有本地时延。^[14]

CAP 讨论的是网络分区发生时，一致性与可用性之间的约束；它不是给数据库贴一个永久“CP/AP”标签就结束选型。正常网络下还存在延迟、复制策略和一致性级别的权衡。产品的不同 API、读模式甚至同一个服务的不同配置，也可能有不同语义。^[14][15]

HTAP 怎样实现，又没有解决什么？

HTAP 指同一系统同时支持事务和分析。TiDB 用 TiKV 行存与 TiFlash 列存承担不同访问模式，并同步数据。这样可以缩短分析数据的链路，但列式副本、数据同步、资源隔离与查询调度仍然消耗资源。^[13]

若分析跨几十个异构源、保留多年历史、含复杂治理与数据科学工作，HTAP 不会自动取代完整数仓。若主要需求是对最新订单做有限分析，它可能减少额外系统。验证时要把“分析查询运行后，交易 p99 是否变差”作为核心指标。

NoSQL 包含差异很大的系统。Redis 的内存数据结构、MongoDB 的文档、Cassandra 的宽列模型和 DynamoDB 的托管键访问，不能统一描述为“没有事务”“没有 schema”或“一定更快”。数据结构和一致性必须落实到具体产品与配置。^{[15][16][17][18]}

缓存与持久化事实源要分清

缓存保存可重建副本，丢失后通常影响延迟和后端压力；事实源丢失则可能影响业务正确性。Redis 的 RDB 快照、AOF 日志及相关同步策略有不同恢复窗口和性能代价。启用持久化之后，还需要检查副本切换、确认语义、内存淘汰以及恢复流程。^[18]

例如，用缓存展示库存可以容许短暂陈旧，但扣库存成功与否仍应由明确的事务路径决定。把同一个数字同步写到主库和缓存，也不意味着两次写入天然原子。

文档模型把复杂度放在哪里？

商品目录中，手机与衣服的属性不同；文档模型允许同一集合中的字段有所差异，经常一起读取的内容可以嵌套。代价是重复数据需要同步，巨大文档和无界数组难以维护。MongoDB 官方同样要求围绕访问模式设计模型，灵活 schema 不等于无需 schema。^[17]

宽列与键值系统偏爱可预测访问

如果主要操作始终是“按设备读某段时间”“按用户读取最近事件”，分区键与聚簇顺序可以让系统高效定位。如果产品经理频繁增加无法预料的跨实体关联与筛选，则可能需要额外索引、冗余表或独立分析层。Cassandra 的查询建模约束与 Bigtable 的行键设计都应在需求阶段讨论。^[16][58]

DynamoDB 还提供一个需要随时间更新的例子：当前全球表文档区分多区域最终一致性 MREC 和多区域强一致性 MRSC，不能再用“DynamoDB 永远只有最终一致”概括整个产品。普通表、LSI、GSI 与 Streams 的读取支持也不同。^[15]

数仓将不同业务源的数据整理成可以复用的指标、维度与历史。云数仓进一步将基础设施、弹性计算、共享、权限与审计产品化。湖仓则试图在对象存储和开放表格式上实现可管理、可靠的分析数据。两条路线不断吸收彼此能力，选型要看实际表类型、数据所有权和使用流程。^{[8][25][26][28]}

Snowflake 的核心价值与边界

Snowflake 的虚拟仓库可以拥有独立计算资源，让不同团队或任务使用不同计算集群，同时访问持久数据。这适合多个部门同时运行 BI、ELT 与数据科学任务的场景；对一个分析师偶尔处理本地文件的需求，平台能力可能超出必要范围。^[8]

计算隔离不意味着业务体验绝对不受其他因素影响，共享服务、元数据操作、数据组织和成本策略仍会起作用。自动扩缩与自动暂停也不意味着账单自动最优：小查询高频唤醒、长时间闲置、重复扫描与后台功能都需要监控。

目前 Snowflake 还包括 Hybrid Tables 与 Snowflake Postgres。前者属于其平台内特定事务能力，后者运行由 Snowflake 管理的独立 Postgres 实例。因此，回答“Snowflake 能不能做 OLTP”，需要先说明使用哪一种产品和表类型。^[8][66]

Databricks 的平台路线

Databricks 将数据工程、SQL、机器学习与治理放在同一平台背景下，适合分析之外还有训练、特征处理、流批流水线和开放数据需求的团队。它的价值不能只用一条 SQL 比 Snowflake 快多少来衡量；组织的工程技能和流程迁移同样重要。^[26]

Lakebase 提供与平台集成的托管 Postgres，包括分支、伸缩等能力，并支持把湖仓数据服务给应用。它说明分析平台正在扩展事务应用入口，但湖仓表与 Postgres 表之间的同步、新鲜度与故障责任仍须核查。^[65]

BigQuery 与 Redshift 的选择逻辑

如果数据、权限和其他服务主要位于 GCP 或 AWS，同云内集成常常影响总成本和交付效率。BigQuery 与 Redshift 都应纳入对应生态的候选，但不能只比较查询界面。应将现有数据位置、收费方式、迁移时间、跨区费用与 BI 工具支持共同计算。^[31][32]

“实时”至少包含两个指标：事件发生到可被查询的数据新鲜度，以及发起查询到返回结果的响应延迟。一个系统可以很快查到昨天的数据，也可以很快摄入却慢慢计算结果。面向终端用户的分析还需要在许多用户同时查询时保持稳定。^[12][40]

ClickHouse 常用于日志、埋点和大量事件聚合；Doris、StarRocks 则把多表分析、实时摄入与数仓能力放在重要位置。Pinot 与 Druid 各有索引、预聚合和事件建模路线。这些是产品定位与架构差异，不能用它们推导一个无条件的速度顺序。^{[12][39][40][41][82]}

从一个查询看选择如何改变

“统计昨天所有访问，按渠道汇总”主要考验扫描、压缩和聚合；“给每个商户展示最近五分钟的转化率”还要求高并发、按租户过滤和持续摄入；“关联用户、订单、商品和退款做灵活探索”更依赖 Join 优化与数据组织。三个任务的数据总量相同，适合的引擎和建模方式也可能不同。

分析数据库中的去重、更新和删除可能通过不同表模型、版本列或后台合并实现。必须验证业务查询何时能看到最终状态。支持 UPDATE 语法与适合作为高并发账户余额主库是不同的判断。

嵌入式引擎减少了一套长期运行的服务器及网络调用。SQLite 主要服务应用本地事务存储，DuckDB 主要面向批量分析，RocksDB 则更接近可嵌入的存储部件。它们都是正式的数据基础设施，并非只适用于玩具项目。^[9][11][50]

DuckDB 为什么受到关注？

分析工作常从 CSV、Parquet、对象存储或内存数据框开始。DuckDB 可以在接近这些数据的位置使用 SQL，利用向量化执行处理列式分析，省去先建立常驻数据服务再导入的步骤。它支持事务，不能称为“只有查询、没有数据库能力的工具”。^[9]

下面是示意查询：本地目录中已有字段匹配的 Parquet 文件，按天和渠道汇总收入。文件路径和列名是示例，不代表已执行的实测。

SELECT
  date_trunc('day', paid_at) AS day,
  channel,
  sum(amount) AS revenue
FROM read_parquet('orders/*.parquet')
GROUP BY 1, 2
ORDER BY 1, 2;

适用边界由数据大小、内存、磁盘、查询形态和并发共同决定。“单机”也不等于“只能处理内存以内的数据”，更不能直接设一个适用于所有项目的 GB/TB 阈值。需要观察落盘、临时空间和资源争用。

2026 年需要更新的并发表述

在进程内原生文件模式中，DuckDB 可以由一个进程读写，进程内允许多个写线程；多个进程只读是另一种模式。当前官方文档还列出 Quack 远程协议，标注为 beta，以及以 PostgreSQL 目录协调多进程读写的 DuckLake 方案。它们不能与“多个独立进程随意同时修改同一个本地数据库文件”混为一谈。^[10]

DuckLake 总览中仍有“原生格式目前不支持该并发模型”的表述，与较新的并发页看似冲突。本报告按模式解释：嵌入式原生文件限制仍应遵守，Quack 是另外引入的客户端/服务器路线；测试阶段与生产可用状态需在部署时确认。^[10][36]

与 Snowflake 如何比较？

一个人分析若干文件时，DuckDB 的低部署成本很有吸引力；多个团队需要统一权限、共享数据、稳定任务和计费管理时，Snowflake 等平台可能省掉大量组织与运维工作。云端 DuckDB 服务还会增加自己的共享、存储和管理层。比较时应写清比较的是开源引擎、某个托管服务，还是完整企业平台。^[8][9][36]

时序数据通常以时间排序，持续写入，按时间窗口查询，并随着时间推移降低精度或删除。真正决定性能的还包括设备数量、标签组合、采样频率、乱序比例、保留期和查询并发。“每秒能写多少点”只是其中一个指标。^{[19][20][21][53]}

监控指标：Prometheus 生态与长期保存

监控通常围绕标签与时间序列查询，告警表达式和采集生态非常重要。标签基数是不同标签组合产生的序列数量；把无界用户 ID 或请求 ID 都作为标签，会造成序列数量膨胀。长保留、跨集群汇聚和高可用则可能需要 VictoriaMetrics 或其他远端存储方案。^[21][54]

Prometheus 本地存储文档明确给出扩展及持久性边界，因此不应把单节点监控存储直接当作没有额外设计的长期审计数据仓库。日志与调用链也不是只有指标一类数据：它们有不同的文本、属性和访问模式。^[21]

工业与物联网：设备模型和数据生命周期

工业场景需要管理大量设备及测点，可能包含端边云传输、断网补传、不同精度和跨时区时间戳。TDengine 与 IoTDB 都围绕此类数据提供模型；InfluxDB 是另一条常用时序路线。若还经常关联设备、工单和业务实体，TimescaleDB 的关系型基础可能降低整合成本。^{[19][20][53][81]}

不能只测试按顺序到达的理想数据。应注入迟到事件、重复记录、错误时间戳、设备重连后的集中补传，以及保留策略触发的删除负载。

行情与交易事件：时间对齐也属于查询能力

金融行情分析常要回答“这次成交发生时，最新报价是什么”，涉及按时间的邻近关联与不规则采样。QuestDB 这类重视时序 SQL 的系统值得评估，但最终还要验证事件时间精度、乱序代价、修正数据和重放一致性。数据库支持金融分析并不自动满足交易系统的全部正确性与恢复要求。^[51]

业务数据库擅长精确条件查询，但用户输入的搜索词可能有分词、拼写、同义词、字段权重和相关性排序问题。搜索系统围绕倒排索引及检索流程设计，还需要结构化过滤、分面统计和更新可见性。Elasticsearch 当前同时提供全文、向量、语义和混合检索。^[22]

一个商品搜索请求“轻便防水的通勤包”，既包含语义，也可能需要价格、库存、品牌和所在地区的过滤。纯向量检索可能漏掉型号、精确标识符；纯关键词也可能漏掉同义表达。混合检索将多路候选结合，再做排序或重排，但每一层都有计算与延迟成本。^[22][23]

多数业务仍需要明确的原始记录保存位置，搜索索引作为可重建的服务层。设计同步时，新增、更新、删除和权限撤销都要覆盖；“最终能同步”不等于“用户在权限变更后不会看到旧内容”。

对规模有限的站内搜索，可以先评估既有数据库的全文能力；出现独立相关性需求、索引规模或服务隔离压力后，再引入专用引擎。Meilisearch、Typesense、Solr 等也属于搜索领域的补充候选，本报告未对这些产品作逐项能力或市场份额比较。

Embedding 将文本、图像等对象映射到数值向量，近邻检索寻找相似对象。近似最近邻索引以可控的召回损失换取计算效率。向量数据库还需要保存标识符和属性，支持过滤、更新、分片、复制及访问控制；这些能力决定它能否稳定接入业务。^[23][46]

通用数据库扩展与专用系统如何划界？

如果已有 Postgres、数据与权限表关系紧密、当前负载可以满足要求，pgvector 可以减少数据副本与运维系统。若检索规模、延迟、独立伸缩或过滤能力成为瓶颈，再将专用向量数据库列为候选。触发条件应该来自实测，不能武断规定“超过一百万条必上专用库”。^[23][46]

Elasticsearch 和 MongoDB 等平台也在吸收向量能力。独立向量厂商竞争的对象同时包括其他专用引擎和客户已有数据库，而不是只有一份独立“向量数据库预算”。^[22][33]

RAG 的失败不一定发生在数据库

一份企业知识文档从导入到被回答，至少经过解析、切块、权限标注、向量生成、索引、候选召回、重排和生成。过时文档、错误切块、权限丢失、问题无法由材料回答，都不能靠更换向量索引自动修复。

测试集需要包含精确编号、中文专有名词、跨文档问题、时间范围、否定条件以及无答案问题。评价既要看 Recall@k，也要看答案是否有证据、权限过滤后是否仍然召回、删除能否在承诺时间内生效。^[22][23]

一笔可复算的容量估算

假设保存 1,000 万个、1,536 维、float32 向量，仅向量数值本身就需要 10,000,000 × 1,536 × 4 = 61,440,000,000 字节，约 61.44 GB，或 57.22 GiB。这个假设算例尚未包括索引、文本、属性、副本、日志和碎片，也不意味着全部字节必须驻留内存。量化或磁盘索引可以改变资源需求，同时要验证召回与延迟。

因此，“每百万向量多少钱”必须同时给出维度、索引、过滤选择性、查询量、更新率、保留副本及计费模式。检索账单还应包含 embedding 重算和 reranker 调用，特别是更换模型后全量重建的成本。

图数据库适合反复进行路径、邻居和连接模式查询，例如资金关系、供应链依赖或知识关系。关系数据库也能表示边表并完成一些递归查询，是否使用图数据库取决于访问模式、路径深度、更新方式与团队维护成本。^[6][24][71]

属性图将节点、边及其属性作为模型中心，Neo4j 是代表；RDF 以三元组表达语义事实，常用于知识互操作。Neptune 的多模型支持让这两种路线在同一产品家族中出现，但模型与查询语言仍需具体选择。图分析引擎、图数据库、图可视化工具也不是完全相同的产品。^[24][71]

在反欺诈案例中，查询“多个新账户是否通过共同设备和收款人形成团伙”需要多跳关系。但图越大、节点度越高，遍历成本也可能急剧增加；应限制范围、时间和深度。GraphRAG 还依赖正确的实体抽取、关系更新及来源追踪，不能仅凭建成知识图谱就断言答案更可靠。

空间数据库处理“点是否在范围内”“道路是否相交”“最近的设施在哪里”。PostGIS 使这些查询进入 Postgres；经纬度的坐标系、球面距离、几何有效性会直接影响结果。它是专业数据类型和算子带来价值的典型例子。^[49]

还有哪些专用家族？

广义范围还包括 RDF 三元组库、多模型库、内存关系数据库、数组数据库、时间版本数据库、对象数据库及传统主机系统。SAP HANA 等内存平台强调特定企业工作负载；金融机构还会使用 kdb+ 等专用时序技术；科研栅格与高维数组有自己的存储和查询体系。它们不能用“都支持存数据”就归成可互换替代品。

本报告主表优先覆盖通用软件工程、分析、工业数据与 AI 检索中较常见的路线。对上述补充家族，不声称已经完成逐产品评测；若目标行业是金融行情、地球科学或主机迁移，需要追加专门调查。版本数据库的双时间模型还应区分“业务事实何时有效”和“系统何时知道这件事”，仅保存一个更新时间字段并不能满足完整历史追溯。

一个典型湖仓包括对象存储、数据文件、表格式、目录、查询计算和治理。Parquet 是列式文件格式；Iceberg、Delta Lake、Hudi 管理表及变更；目录帮助引擎发现与提交表状态；Trino、Spark 等承担计算。没有任何一层可以仅凭名称自动替代全部其他层。^{[25][27][28][74]}

开放格式提供了什么？

Iceberg 提供 schema 演进、隐藏分区、快照与回滚等机制，让多个计算引擎有机会使用同一份数据。Delta 与 Hudi 也提供事务、更新和增量处理等能力。好处包括减少某些重复导出，以及更灵活地选择计算；实际互操作还取决于各引擎实现了哪些协议版本和特性。^[25][28][74]

开放文件格式不能保证一切迁移都容易。目录中的权限、平台函数、作业编排、物化视图和监控仍可能绑定服务商。两套引擎都能读取 Parquet，也不证明它们可以安全并发更新同一事务表。

小文件、目录与维护费用

持续摄入会产生小文件，查询需要打开更多文件并处理更多元数据；合并、快照过期和删除文件清理则消耗计算。只对比对象存储的每 GB 单价，会漏掉这些维护成本。DuckLake 使用 SQL 数据库保存目录元数据，提供另一种协调方式，目录数据库因此也进入可用性与备份范围。^[36]

联邦查询不意味着数据移动消失

Trino 可以连接异构源执行 SQL，但跨源 Join 需要由连接器、源端下推和执行引擎合作完成。一个慢源或无法下推的过滤条件就可能拖慢全局查询。对高频生产报表，适当落地、缓存或预聚合可能比每次跨多个在线业务库查询更可靠。^[27]

事件流平台保存与分发事件，流处理引擎转换和关联事件，流式数据库则进一步把持续维护的结果作为查询接口。三者可以组合，也有产品试图合并多个职责。理解它们的状态与恢复边界，比统计组件数量更重要。^[29][30][73]

“最近五分钟每家店的支付金额”如果每次都扫描原始事件，查询越多，重复计算越多。增量计算在新事件到来时更新结果，查询读取已维护状态；代价是持续占用计算和状态存储，而且要定义迟到、撤销、重复事件与窗口关闭方式。^[29][30]

端到端 exactly-once 取决于来源重放、计算状态和输出提交能否协调。一个处理引擎能恢复 checkpoint，不证明外部邮件、支付或非事务写入不会被执行两次。数据库消费者仍需要幂等键或适合的提交机制。

IDC 的 2025 年中国本地部署事务型数据库报告在 2026 年 9 月发布，公开摘要称该市场同比增长 13.2%，并提到国产厂商登上份额首位。摘要没有给出完整厂商占比，本文不推断具体第一名或其百分比。这个口径也不包括所有云数据库和分析型数据库。^[35]

腾讯云转载的 IDC 历史材料还给出：2024 年上半年中国关系型数据库软件市场为 19.3 亿美元，其中公有云 12.9 亿美元、本地部署 6.4 亿美元。同一材料可以算出当期公有云约占 66.8%，但不能与全球 DBMS 的 64% 直接排榜，因为地域、时间与品类范围不同。^[87]

分四组看参与者

上表为生态分组，不是排名或统一“国产化率”。官方文档可验证产品和部分技术路线；项目出身、商业主体、发行版来源、自主可控或采购资格是不同问题，本文不从品牌归属推断合规结论。^{[13][39][53][68][69][81][82][83][87][89]}

迁移难点常出现在 SQL 之外

复杂过程、触发器、序列、日期时间、字符排序规则、隐式类型转换、分页语义、驱动行为和管理工具，都可能影响迁移。真正的验证应从生产语句分布、关键事务和回滚演练出发，先在影子或回放环境比较结果，再讨论切换。

例如，源系统按某种大小写不敏感规则建立唯一约束，目标系统的排序规则不同，就可能出现以前能插入、现在不能插入，或者以前被视为重复、现在被视为不同的记录。应用能连上、基础 SQL 能运行，仍不能证明业务语义一致。

本地采购还要看项目实施、支持、培训、后续升级与回款周期。对商业分析，开源下载、签约额、收入确认和持续订阅应分开；将一次性替换项目都看成高续费云订阅，会误判企业的经营质量。

数据库软件的开发、交付与使用者可能属于不同主体。Postgres 项目、托管 Postgres 服务商和使用 Postgres 的企业形成不同经济角色。社区采用带来人才、工具和信任，但由谁捕获商业价值，要看产品封装、渠道和客户关系。^{[6][61][65][66]}

壁垒如何形成？

数据库替换成本来自多年积累的查询、数据、工具、团队技能和事故处理经验。可靠性尤其难通过短期演示建立。对企业客户，治理、审计、跨区域能力、迁移工具和支持响应可能比单次性能领先更影响采购。

新厂商则可以在旧平台表现不佳的场景建立入口：面向用户的实时分析、开发环境分支、工业时序、复杂混合检索等。一旦通用平台吸收相同能力，独立产品就需要证明持续的质量或成本优势，或者扩大工作流覆盖。这是竞争分析，不能直接推出某家厂商一定获胜。

性能优化与营收增长可能方向相反

消费计费下，查询变快、扫描变少，客户对同一工作量的支出可能下降。更低成本又可能促成更多工作负载迁入。因此，应同时看单位工作负载成本、总消费、留存、客户扩展和毛利，不能仅凭产品更快就预测厂商收入更高。Snowflake 的产品收入和 Databricks 的年化运行率采用不同定义，尤其不宜直接做增速排榜。^[34][62]

授权条款属于产品边界

Redis 的授权变化说明“是否开源”需要版本和许可证名称。Redis 8 官方发布说明包含 AGPLv3 选项，同时保留 RSALv2、SSPLv1 等选择；把它简单描述为“从此闭源”会遗漏后续变化。Valkey 则是另一条项目路线。^[37][47]

本文不提供逐项法律判断。实际采购或产品集成时，应读取计划使用的版本许可证、扩展与托管合同，特别关注分发、网络服务、嵌入和再提供数据库服务的用途。项目代码可见、OSI 意义的开源与可自由提供商业托管不是同一句话。

以下是工程筛选建议，不是对某家产品的无条件推荐。已有团队经验、地域、恢复目标和采购约束可能改变候选顺序。

案例一：从一套主库开始的 SaaS

假设一家中小型 SaaS 需要客户、订单、权限和审计记录，可先使用 Postgres/MySQL 保存核心事实，配合对象存储保存文件。只有在监测到重复热点读取或明确缓存需求时增加 Redis；需要复杂全文检索时增加搜索服务；分析拖累主库时再通过 CDC 或批处理构建分析层。

这条路线的停止条件是现有系统已满足正确性、延迟与恢复目标。数据库数量少并不自动更好，数量多也不是架构成熟的证明。每引入一份数据副本，都要写清如何生成、如何删除、能陈旧多久、出错后怎样重建。

案例二：工业设备数据加业务工单

假设系统持续接收设备测点，又要查询设备属于哪个客户、哪些工单尚未关闭。若设备数据模型与写入规模居主导，可以评估专用工业时序库，业务实体保存在关系数据库，并设计查询汇合点。如果强关联查询很多、规模和写入允许，TimescaleDB 一类路线可减少跨系统连接。原始历史还可归档至对象存储供后续分析。^[19][53][81]

验证重点包括断网一小时后的补传、时间戳回拨、设备重复上报和保留期删除。只用均匀持续写入跑分，会低估现场问题。

案例三：企业知识问答

原始文件保存在可追溯的位置，关系数据库保存文档版本、组织与权限，检索层保存 chunk、向量和过滤属性。检索候选必须与用户权限一致，最终答案保留来源与版本。选择 pgvector 或独立向量库之前，应对真实问题集比较过滤后召回、重排效果、成本和运维。^[22][23][46]

一个重要故障演练是撤销某人的文件访问权限，确认索引、缓存和答案链路在目标时间内都停止泄露旧内容。仅测相似问题“能答对多少”不够。

案例四：全球交易与实时经营分析

交易层按一致性与地域目标选择关系型或分布式 SQL；事件通过有明确语义的链路进入实时分析层；企业统一指标和历史数据进入数仓或湖仓。对于某些范围清楚的业务，HTAP 可以合并交易与分析职责；是否合并取决于分析负载对交易尾延迟和恢复的影响。^[13][14][40]

交易成功与报表更新之间要给出允许的时间差。若要求两者严格同步，应重新评估事务和发布边界，不能简单缩短轮询间隔就声称实现强一致。

总拥有成本包含哪些项？

可用的表达式是：总成本 = 许可或订阅 + 计算 + 存储与副本 + I/O 与网络 + 数据管道 + 人员运维 + 迁移摊销 + 故障影响。其中故障影响通常是场景估计，应与真实账单分开。自建可以降低某些软件费用，托管可以减少部分劳动，但都不能将另一侧设为零。

下面是一组完全虚构、用于演示方法的月度预算，单位为人民币，不是任何厂商报价或当前价格。假设比较的是同一业务 SLO、同一备份和同一数据量：

若 A 的日常人力降至 0.1 人月，其合计变为 15,000 元，结果反转。因此，直接把托管账单和自建服务器账单放在一起比较，会漏掉决定结论的人员假设。类似地，数仓的查询优化既降低客户成本，也可能改变厂商的收入增长。

不同数据库的主要成本驱动

一份有意义的 PoC 清单

1. 固定正确性目标。 明确事务边界、允许丢失的数据量 RPO、恢复时间 RTO、权限与删除时限。
2. 准备真实形态的数据。 保留倾斜、热点、大对象、空值、重复、乱序、历史版本和高基数，不只生成均匀随机数。
3. 固定比较条件。 记录版本、硬件、索引、复制、耐久性配置、数据冷热状态、并发、缓存与费用；不同条件的跑分不得合并。
4. 测整个工作负载。 同时运行写入、查询、后台合并、备份和回填，观察吞吐及 p50/p95/p99，而非只有平均响应。
5. 注入失败。 停节点、断网络、耗尽磁盘、触发切换、恢复备份；验证数据结果和应用重试，不只看监控转绿。
6. 验证退出路径。 导出与还原、CDC 重建、schema 升级、批量删除、切换回滚；记录耗时与人工步骤。
7. 检查 30 天后的维护成本。 索引和状态会长大，数据会过期，初次演示的表现未必代表稳态。

供应商公布的基准有助于复现特定实验，但测试数据、查询集合、冷热缓存和耐久性设置都会改变结果。本文没有用供应商单一跑分宣布某数据库“最快”。如果把恢复保障关掉换取高吞吐，就应该明确它已经变成另一种服务目标。

以下时间窗是研究框架。事实栏描述本次确认的产品和机制；判断栏是推断；反证条件用于检查预测是否仍成立。没有为无法校准的预测填写虚假的概率。

AI 将改变什么，短期难以改变什么？

自然语言生成 SQL 可以降低部分查询门槛，却不能自动确定企业中“收入”“活跃用户”“有效订单”的定义。更容易写出查询，反而可能增加大扫描、错误 Join 与越权访问。语义层、权限检查、查询预算和结果审计因此值得关注。

AI 辅助索引、参数调优与故障诊断有潜在价值，但自动执行需要可验证前提：输入信息足够、变更范围明确、影响可观测、能够回滚。业务规则、跨系统事务与恢复目标并不会因为助手能生成命令而消失。

硬件与算法：研究单位工作量，而非抽象倍数

向量化执行、压缩、更好的索引与存储分层已经是主要优化路线。GPU、快速网络、计算存储分离和学习型优化可能继续改变某些负载的成本，但收益受数据搬运、更新频率、并发和硬件利用率制约。值得验证的是“相同正确性与 SLO 下，每次有效业务操作的成本”，不是脱离使用场景的理论峰值。

三种可能并存的产业结果

平台集中：企业更重视集成采购和治理，云平台在多类数据库间交叉销售。独立厂商需要证明差异化，或被整合进更大平台。

开放数据、多引擎计算：企业保留开放数据格式，按工作负载选择引擎，价值向目录、权限、调度和服务可靠性移动。

垂直专用继续生存：工业时序、复杂关系、低延迟实时分析和大规模检索仍有难以被通用平台完全满足的需求。

这三种情景可以发生在不同客户身上。研究时应观察预算从何处转移、总成本是否下降、客户是否持续使用；不必假设数据库市场最终只剩一种架构。

课题 A：已有 Postgres 是否足够支撑企业检索？

比较 pgvector 与一个专用向量系统，固定 embedding、切块、数据、过滤条件和机器成本。使用不同过滤选择性、冷热数据、更新频率和查询并发，记录 Recall@k、p95/p99、写入到可见延迟、删除生效时间和总费用。不要只比较没有过滤的随机向量检索。

采用门槛由业务预先指定，例如权限正确率必须达到全部测试通过，召回和延迟达到目标后再比较成本。若专用系统没有明显收益，就保留已有系统；若主库资源竞争明显或召回/过滤无法满足，则评估拆分。^[23][46]

课题 B：实时分析能否减少产品后端的预计算？

以一个真实租户看板为样本，比较现有预聚合方案与两种实时分析候选。包含小租户、大租户、复杂 Join、突发查询和历史回填。观察用户可见的新鲜度、峰值 p99、摄入失败与每千次成功查询的费用。不能用只读静态数据集代表边写边查。

课题 C：开放湖仓是否真的降低迁移成本？

选择一张有更新、删除和 schema 演进的表，让两个引擎读写目标格式。执行快照回滚、并发更新、删除文件清理和目录恢复。记录兼容问题、运维工时及所需特性。若开放性只能在不使用关键功能时成立，应把这个约束写进迁移计划。^{[25][28][36][74]}

课题 D：多地域事务值不值得引入？

用实际业务键分布回放交易，设置跨区网络延迟、区域不可用与热点。测量成功率、重试放大、提交时延与恢复行为，再与“单写区域加异地灾备”比较。如果业务并没有多地写入必要，多地域强一致架构可能增加成本而没有相应收益。^[14][55][56]

课题 E：数据库 Agent 能否安全地完成一类运维？

从只读诊断开始，提供脱敏 schema、查询计划、指标和故障记录，要求每个结论关联证据。再在隔离环境测试索引建议、参数修改或分支恢复。记录错误建议、无法察觉的副作用、权限越界与回滚时间。只有范围有限、结果可验证的工作通过门槛后，才考虑扩大自动执行范围。

预研的成功也可以是确认“不必更换数据库”。只要实验减少了架构不确定性，避免未来重复试错，就已经产生价值。

五个深入阅读入口

1. 先读 SQLite 的适用场景。 它用非常具体的部署与并发边界解释选型，适合作为摆脱“更大系统总是更好”的起点。^[11]
2. 再读 DuckDB 的设计目标与并发文档。 将引擎定位、执行方式与部署模式联系起来，并留意动态版本说明。^[9][10]
3. 读 Spanner 的外部一致性。 理解严格事务语义与跨地域系统之间的关系。^[14]
4. 读 Iceberg 的表格式说明。 将文件、表、快照、目录与计算层分开理解。^[25]
5. 读 pgvector 与 Qdrant 的实际检索文档。 重点看索引、过滤与性能边界，再回到 RAG 的完整链路。^[23][46]

本版的明确缺口

全球及中国的完整最新厂商收入份额，仍需有授权的同年度原始报告；向量、时序、图和嵌入式的统一收入口径尚不充分。本版没有对全部候选作独立性能评测，也没有完成每个产品在每个国家、云区域和发行版中的功能核验。

这些缺口不妨碍建立分类与选型框架，但会限制精确市场规模分配、采购评分和投资估值。正式采购应补充报价、实际合同、版本清单和业务 PoC；引用动态产品能力或市场数据时，应再次核对原始来源的日期与适用范围。