首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >长文:国产开源数据库盘点与思考

长文:国产开源数据库盘点与思考

作者头像
jeanron100
发布2026-03-10 13:06:58
发布2026-03-10 13:06:58
900
举报
0.png
0.png

近期,一款国产数据库开源的消息引起我的关注。针对数据库的开源,好像已经是很久远的事情。曾几何时,数据库开源是个很“时髦”的事,也吸引了大量技术人员的关注。那么如今,这些开源数据库又发展的如何呢?国产数据库的开源生态又怎样呢?笔者对主流的国产开源数据库做了个整理,从中一窥当前的国内开源现状。

1. 开源必须回答的几个问题

在谈国产开源数据库之前,我们先尝试回答几个问题。这些问题也是开源圈大家经常关注的问题。也许有些观点比较刺耳,但还是有必要讲一讲的。

1).开源的目的是什么

对于数据库这类基础软件而言,开源的目的更是多元而复杂,交织着技术理想、商业考量和市场现实。深入剖析,其主要动机可归纳为以下几类:

✦ 目的之一,生态构建与破局

数据库的成功,产品力只是基础,其成败还取决于周边生态的繁荣程度——包括可视化工具、数据同步服务、ORM框架、以及丰富的应用案例。国产数据库起步较晚,在面对Oracle、MySQL、PostgreSQL等国际巨头早已构筑的庞大生态壁垒时,单打独斗难有胜算。通过将全部或核心代码开源,能极大地降低开发者的学习和试用成本,吸引一批早期的采纳者、贡献者和合作伙伴。他们基于该数据库构建工具、开发应用、贡献代码,从而像滚雪球一样,快速形成一个围绕该数据库的技术共同体。例如华为开源openGauss,正是希望借助社区力量,打破生态的垄断,打造一个根植于中国的数据库生态体系。这是目前国产数据库开源最核心、也最现实的目标。

✦ 目的之二,产品与市场匹配(PMF)

这一目的在工具型产品中尤为显著,通过开源,项目可以直接暴露在最真实、最苛刻的生产环境中,接受海量用户和各类极端场景的检验。社区用户提交的Issue和Pull Request成为了最宝贵、最直接的产品反馈,驱动着产品快速迭代和架构优化。这种“在实战中打磨”的方式,远胜于闭门造车。然而,在纯粹的toB(企业级)商业模式下,这一点的有效性会打折扣。企业级客户更看重的是稳定性、安全性和官方支持,他们通常不愿在核心业务上贸然采用一个由社区驱动的、尚未经过充分验证的版本。因此,对于定位高端企业市场的数据库,开源版本更多是充当一个功能可能稍逊但足够可靠的“体验版”,其PMF的验证更多地依赖于与头部客户的深度共创,而非广泛的社区反馈。

目的之三,为商业转化铺路

经典的“开源商业模式”如Open Core(开放核心:基础版开源,高级特性付费)或提供云托管服务,在国际上有Confluent、MongoDB等成功先例。其逻辑是通过开源版本构建庞大的用户池,再从中转化有高阶需求的企业客户。然而,在中国市场,这一路径至今未有被广泛认可的成功案例。原因在于,国内客户为软件付费的意愿本就相对薄弱,尤其难以接受为“高级功能”或“技术支持”支付高昂费用。更严峻的是,云厂商的“搭便车”行为——即直接将开源软件打包成商业化云服务,却无需回馈核心项目——极大地挤压了原厂的盈利空间。因此,希望通过开源直接实现大规模商业变现,在当前环境下更像一个美好的愿景而非可靠的战略。

✦ 目的之四,成为融资的“敲门砖”

在资本市场追捧“硬科技”和“国产替代”概念的风口期,一个高Star数、高活跃度的开源项目,是技术实力和品牌声量的最佳证明,能显著提升公司在投资机构眼中的估值。然而,随着资本市场的理性回归,投资逻辑已从“看故事”转向“看营收”。如今,若一个开源项目无法展现出清晰的商业化路径和真实的收入能力,仅凭开源热度已难以获得资本的持续青睐。

✦ 目的之五,情怀与战略投入

少部分大型科技公司开源其内部久经考验的数据库(如阿里开源AliSQL),既有反哺社区、推动行业技术进步的理想主义色彩,也是一种提升公司技术品牌形象、吸引顶尖人才的战略举措。这种“情怀”背后,是强大的财力支撑和长远的生态布局,而非中小创业公司可轻易模仿。

从上述目的可见,数据库的开源是一项充满战略智慧的举措,企业需要明确开源的目的,在当前严峻的市场环境下,理性看待开源的目的,有助于企业制定更符合自身实际的、可持续的开源战略。

2).开源与商业版本的差异

数据库产品的开源与商业版本之间存在差异,这是一种普遍行业现象(参考文章 )。这种差异更多是商业策略的考虑。厂商需要可持续的营收来支撑庞大的研发团队和长期的生态建设。常见的策略是采用“开源核心,商业增值”的模式。即将基础、稳定、能满足大多数开发者学习和轻量级应用需求的版本开源,以此降低使用门槛,快速获取用户关注和社区影响力,构建生态基石。而将那些企业级客户在核心生产环境中迫切需要的关键能力,设置为商业版本的核心价值。这些能力通常包括:高阶运维功能(如可视化监控、智能诊断、一键巡检)、高级安全特性(如数据脱敏、列级权限控制、审计日志)、官方原厂技术支持(SLA服务保障、紧急漏洞修复)以及与商业化云平台深度集成的托管服务。

正因如此,企业在技术选型时,必须清醒地认识到这些差异点。选择开源版本,绝不能仅评估其基础性能,更要深入调研商业版本所独有的能力是否为自己未来业务所必需。例如,一个在测试中性能卓越的开源数据库,可能缺乏生产环境必需的便捷备份恢复或高可用自动故障切换工具,这些“能用”和“好用”之间的差距,往往是项目能否在线上稳定运行的关键。忽视这一点,可能导致项目后期面临巨大的运维风险或高昂的二次开发成本。

在市场上,确实存在开源商业的平衡挑战:如果开源版本过于强大,功能过于完善,反而会削弱客户购买商业版本的意愿,导致“开源悖论”。因此,厂商在决定“哪些能力放入开源,哪些能力保留给商业”时,无异于一场战略赌博。这需要精准洞察目标客户的核心痛点和付费意愿,确保开源版本有足够的吸引力,同时商业版本又能提供不可替代的增量价值。然而,在国内市场,从开源版本向商业版本的导流逻辑显得异常脆弱。一方面,国内用户为软件许可付费的意愿本就相对较低,更倾向于通过自身技术力量克服开源版本的局限性;另一方面,云厂商的“搭便车”行为进一步挤压了原厂的商业化空间。这使得希望通过开源快速积累用户,再自然转化为付费客户的路径,在实践中屡屡受挫。

3).开源商业化的路径成立嘛

数据库从开源到商业化的路径,是一个在全球范围内被广泛探讨且已被验证可行的模式,但在中国特定的市场环境下,这条路径的畅通性则需打上一个大大的问号。正如文章所谈到的主流商业模式:提供增值服务(如RedHat)、采用双版本策略(Open Core,如Elastic)以及提供云托管服务(Hosting,如MongoDB),都证明了开源软件具备强大的商业潜力。其背后的经济学原理在于,将核心代码这一边际成本近乎为零的部分免费开源,以此快速占领市场、构建开发者生态,最终通过互补品(高级功能、技术支持、云服务)实现价值变现。

然而,将视线转回国内,上述这些在国际上通行的路径却面临着“水土不服”的严峻挑战,迄今为止尚未诞生一个可与国际巨头比肩的、通过纯粹开源模式实现大规模商业化的数据库公司。其根源在于中国独特的市场环境:首先,企业客户为软件许可付费的意愿相对较低,尤其难以接受为“技术支持”或“高级功能”支付高昂费用,这使得“增值服务”和“双版本”模式的溢价能力被削弱。其次,国内云计算巨头往往将优秀的开源数据库直接封装为云服务进行低价销售,这种“搭便车”行为严重侵蚀了原厂通过“云托管”模式盈利的空间,形成了“开源成果被公有云收割”的困境。

因此,国内的数据库厂商必须回归理性,重新审视开源的核心目的。如果仍将“直接商业转化”作为开源的首要乃至唯一目标,在当前环境下很可能事与愿违。开源更现实的价值在于生态构建和产品打磨,即通过开放源代码快速获取开发者信任、积累真实场景的使用反馈、奠定市场影响力。在此基础上,厂商需要探索更符合国情的商业化路径,例如:将开源版本与深度的行业解决方案绑定,打造无法被简单云化的“产品+服务”一体化交付模式;或是在开源协议上进行创新,在鼓励社区参与和保护商业利益之间寻找新的平衡点。总而言之,开源绝非商业化的捷径,而是一条需要长期主义、战略耐心和本土化创新思维的漫漫长路。

4).开源项目能上生产吗
1.PNG
1.PNG

将开源数据库用于生产环境,绝非简单的技术选型替换,而是一场需要彻底转变思维模式的战略决策。企业必须清醒地认识到,使用开源数据库与采购商业数据库存在着本质区别,这意味着一套完全不同的责任与能力体系。商业数据库提供的是一站式的“交钥匙”工程,其价值不仅在于软件功能,更在于隐含的SLA服务保障、明确的责任边界以及完善的高级特性(如可视化运维平台、高级安全功能、智能诊断等)。而选择开源版本,企业获得的往往是一个强大的“引擎”,但如何打造一辆能安全、稳定行驶的“整车”,则需要自身或借助第三方力量来填补从安装部署、监控告警、备份容灾到性能优化的全部能力空白。这意味着企业技术团队需要具备深厚的运维能力和源码级的问题排查能力,或者需要付费购买可靠的第三方技术服务,否则将面临巨大的运维风险。

在中国特定的环境下,使用开源有一挑战尤为突出,就是如何解决“兜底、背责”的问题。商业数据库厂商之所以收费高昂,一部分价值正是为其产品提供最终的责任担保(背锅)。当核心业务数据库出现严重故障导致业务停摆时,企业有明确的法律和合同依据向厂商追责。然而,在使用开源数据库时,这一“保险”机制几乎缺失。开源社区遵循“按原样提供”的原则,不承担任何责任。虽然国内也涌现出一些提供开源数据库技术服务的公司,但其品牌背书、资金实力和承担损失的能力,与Oracle、微软等国际巨头相比往往不可同日而语。这使得许多对稳定性要求极高的企业,尤其是金融、电信等关键行业,在是否将开源数据库置于核心生产环节时踌躇不前,因为无人“背责”的潜在风险过高。

此外从成本角度进行深入评估,我们会发现,使用开源数据库很多时候并非一种“经济”的选择,其总拥有成本(TCO)可能远超预期。这绝不仅仅是软件许可费为零所呈现的表面节约。真正的成本蕴含在多个方面:首先是人力的高投入,需要组建一支既懂数据库内核又精通运维的高水平团队,这类人才的人力成本极其昂贵;其次是运维体系的构建成本,需要自行或外购搭建一整套运维管理平台;再者是潜在的故障风险成本,由于缺乏原厂第一时间的技术支持,故障恢复时间可能更长,导致的业务损失巨大。因此,企业在决策前必须进行全面的成本效益分析,将所有这些隐性成本计算在内,才能做出符合自身长期利益的理性判断。

综上所述,开源数据库上生产在技术上是完全可行的,但其成功与否高度依赖于企业自身的技术实力、风险承受能力以及对总拥有成本的综合考量。对于大多数企业而言,这并非一个更便宜的选项,而是一个将更多责任和控制权揽入怀中的选择,需要慎之又慎。

2. 国内数据库开源观察

2.PNG
2.PNG

这是来自2023年艾瑞收集的国产数据库情况,其中部分开源项目已经不活跃了。下面我收集了部分国产主流开源数据库的情况,通过表格形式体现。需要说明的是,特增加了开源指标和活跃度两个指标。前者是开源项目常见指标(Stars,Forks,Contributors),可以大体反映开源项目发展程度;后者通过开源项目的变化情况(Active PR/Month,Active Issue/Month)在一定程度上反映开源项目的活跃度。此外,有的开源项目有多个开源地址,这里主要选取Github的数据,如没有则选择其他开源托管平台如Git的数据。

3.png
3.png
观点:项目参差不齐,活跃差异巨大

国产数据库开源领域呈现出显著的“冰火两重天”景象,项目之间的数量级差异巨大,反映出社区影响力和开发活跃度的高度不均衡。这种差异不仅体现在表征受欢迎程度的Star数量上,更关键地体现在反映实际开发活力的PR、Fork、Issue等动态指标上。一方面,头部项目已经具备了国际级的社区影响力与活跃度。以 TiDB 为例,其Star数一骑绝尘,远超其他项目,同时PR、Fork、Issue的数据,构成了一幅健康、活跃的开源项目图景,表明有一个庞大的开发者社区在持续为其贡献代码、报告问题并参与协作。类似地,Milvus、TDengine、OceanBase等项目,不仅在知名度上领先,更在实质性的社区协作上表现出强劲势头。这些项目通常由成熟的团队运营,有清晰的版本迭代路线图和活跃的社区沟通渠道。另一方面,大量项目的活跃度则处于较低或甚至停滞状态。这种差距触目惊心,有些项目其Star数仅为个位数,PR、Fork、Issue数长期很低,这通常意味着项目可能已无人维护或仅作为代码存档开放。这种巨大的差异揭示了开源世界的残酷现实,仅仅开源代码并不足以成功,持续的社区运营、技术布道和商业支持才是维持项目生命力的关键。用户在选型时,绝不能仅凭Star数做判断,必须综合考察PR、Issue、版本发布频率等动态指标,以避免选用一个“僵尸项目”。

观点:新兴数据库类型更为活跃

从数据中可以清晰地观察到,国产开源数据库的活力正从传统的关系型数据库领域,向时序、向量、图、OLAP等新兴和专业型数据库转移。这些赛道由于切中了AI、物联网、实时分析等当下最前沿的技术趋势,获得了开发者社区和资本市场的双重青睐,表现出更高的活跃度和关注度。传统关系型数据库虽然项目数量众多,但除个别明星项目外,整体面临的竞争压力巨大。 在PostgreSQL和MySQL衍生品阵营中,只有 TiDB、OceanBase、IvorySQL等少数几个在分布式架构上取得突破的项目脱颖而出,获得了现象级的关注;而其他许多同类项目社区指标相对平淡。这表明,在高度成熟的关系型数据库市场,除非有颠覆性的技术优势或强大的生态背书,否则新项目很难吸引到广泛的社区注意力。相比之下,面向特定场景的新兴数据库则表现出了惊人的爆发力。如Milvus,受益于当前大模型和AI应用对向量检索的迫切需求,非常火热。其他如时序数据库领域的 TDengine 和 Apache IoTDB,也因其在物联网、工业制造等场景下的高效能而备受关注。在OLAP领域,Apache Doris 和 StarRocks 作为实时分析引擎的后起之秀,社区活跃度非常高。

观点:开源协议多样化,商业化考量明显

国产开源数据库在开源协议的选择上呈现出明显的多样性,这背后反映了项目主导方对于知识产权、商业模式和社区推广的不同战略考量。协议选择不再是单纯的技术或法律问题,而是与项目的商业化路径紧密相连的战略决策。Apache-2.0协议成为绝对主流,体现了“开放核心”或云服务商业模式的偏好。在列表中的众多项目中,如TiDB、PolarDB-PG、PolarDB-X、Apache Doris、TDengine、Milvus、Databend等均采用Apache-2.0协议。该协议非常宽松,允许用户自由使用、修改和分发软件,甚至用于商业闭源项目,这极大降低了开发者的使用门槛,有利于快速构建社区和生态。对于项目方而言,这种宽松性为其“开放核心”(Open Core)商业模式奠定了基础,即核心代码开源,但高级特性、企业级功能或托管服务(通常以云服务形式)则需付费。阿里云、百度飞轮科技等公司的项目多采用此协议,其最终目的是通过开源吸引用户,并导向其商业云服务。

存在使用Copyleft协议的项目,旨在保护知识产权并促进协作。例如,GreatSQL 和 AliSQL 选择了 GPL-2.0协议,openHalo使用了 GPL-3.0 协议。GPL系列协议具有“病毒式”传播特性,要求任何修改后的衍生作品也必须以相同协议开源。这在一定程度上可以防止其他公司直接将其代码闭源商业化,保证了项目的主导权。TDengine社区版采用了更强的AGPL-3.0协议,该协议对云服务提供商有更严格的限制,是项目方在云时代保护自身商业利益的一种常见策略。另一方面,华为的 openGauss 和天翼云的 openTeleDB 则选择了中国本土的MulanPSL-2.0(木兰宽松许可证),它与Apache-2.0类似,是宽松协议,体现了对国产开源协议的支持。

协议的选择直接影响了项目的采用和商业化路径。 宽松协议项目更易被广泛采用和集成,但竞争也更激烈;Copyleft 协议项目能更好地控制代码分支,但可能吓退一些寻求专有集成的商业用户。从数据看,国产开源数据库主导方已经非常成熟和理性地运用开源协议这一工具,在“构建开放社区”和“实现商业回报”之间寻求最佳平衡点。这种多样化的协议格局,正是国内开源商业生态逐步成熟的体现。

3. 国产开源数据库盘点

下面罗列下国内主要的开源数据库。说明下,顺序不代表排名。

IvorySQL

https://www.ivorysql.org/zh-cn/

https://github.com/IvorySQL/IvorySQL

IvorySQL是先进的、功能齐全的开源兼容Oracle的PostgreSQL数据库,并坚定地承诺始终保持100%兼容并直接替换最新的 PostgreSQL。IvorySQL添加了一个“compatible_db”切换开关以在Oracle和PostgreSQL兼容模式之间切换。IvorySQL的一大亮点是支持oracle的PL/SQL语法和Oracle风格包的PL/SQL过程语言。该项目已捐赠给开放原子开源基金会。

4.png
4.png
openTeleDB

https://github.com/OpenTeleDB/OpenTeleDB

OpenTeleDB 基于 PostgreSQL 17 开发,PostgreSQL 是一个开源的对象关系型数据库系统,以健壮性、完整性、功能强大著称。它支持复杂的查询,外键,事务完整性,MVCC。其架构由后端(处理数据存储,查询和事务)和前端(客户端应用与数据库交互)组成。OpenTeleDB 新增三大特性,XProxy、XStore和XRaft。XProxy 是针对高并发、大规模连接场景下数据库性能瓶颈与运维复杂性问题所孵化的自主创新解决方案,旨在应对传统数据库在短连接高频访问下连接开销大、并发能力受限、读写分离实现复杂等挑战。XStore 是针对高并发的OLTP场景、要求性能稳定的业务所设计的原位更新存储引擎。XRaft 是针对传统数据库高可用架构中数据一致性风险与脑裂问题所孵化的自主创新解决方案,旨在应对主备切换时日志分叉引发全量重建、故障转移依赖外部仲裁导致系统性风险等核心挑战。

5.png
5.png
openHalo

https://www.openhalo.org/

https://github.com/HaloTech-Co-Ltd/openHalo

openHalo 能够理解 MySQL 的 SQL 方言,并支持相同的通信协议,MySQL 编写的应用程序只需进行少量甚至无需任何代码更改即可与 openHalo 兼容。这样一来,将运行在 MySQL 5.7 或更高版本上的应用程序迁移到 openHalo 所需的工作量大大减少,从而实现更快、风险更低、成本更低的迁移。

6.png
6.png
openGauss

https://opengauss.org/zh/

https://gitcode.com/opengauss/openGauss-server

https://github.com/opengauss-mirror/openGauss-server

openGauss 基于C++语言实现,重点面向企业级应用场景提供数据管理服务。该系统采用多核架构性能优化、全密态计算安全机制及AI智能调优技术,支持一主多备架构与最多八个备机的部署模式,适用于金融、通信等高并发场景。开源后与130余家合作伙伴共建社区,2023年开发者大会推出DataPod+DataKit组合及第三代智能优化器ABO,并发布数据库一体机产品。累计装机量突破10万台,线下集中式新增市场份额达30.2%,基于该技术的产品占比超过MySQL和PostgreSQL,成为主流开源技术路线之一。其技术特性包括故障切换时间10秒内、两路鲲鹏处理器性能达150万tpmC,提供端到端安全防护及AI智能参数调优能力。2024年开源数据库项目获中国通信学会科学技术奖一等奖,并获得首个自主创新数据库根社区认证证书。

7.png
7.png
PolarDB-PG

https://github.com/ApsaraDB/PolarDB-for-PostgreSQL

PolarDB for PostgreSQL是一款阿里云自主研发的云原生数据库,100% 兼容 PostgreSQL,采用基于 Shared-Storage 的存储计算分离架构,具有极致弹性、毫秒级延迟、HTAP 的能力。PolarDB for PostgreSQL 采用了基于 Shared-Storage 的存储计算分离架构。数据库由传统的 Shared-Nothing 架构,转变成了 Shared-Storage 架构。由原来的 N 份计算 + N 份存储,转变成了 N 份计算 + 1 份存储。虽然共享存储上数据是一份,但是数据在各节点内存中的状态是不同的,需要通过内存状态的同步来维护数据的一致性;同时主节点在刷脏时也需要做协调,避免只读节点读取到超前的 “未来页面”,也要避免只读节点读取到过时的没有在内存中被正确回放的 “过去页面”。为了解决该问题,PolarDB 创造性地设计了 LogIndex 数据结构来维护页面的回放历史,该结构能够实现主节点与只读节点之间的同步。在存储计算分离后,I/O 单路延迟变大的同时,I/O 的吞吐也变大了。在处理分析型查询时,仅使用单个只读节点无法发挥出存储侧的大 I/O 带宽优势,也无法利用其他只读节点的 CPU、内存和 I/O 资源。为了解决该问题,PolarDB 研发了基于 Shared-Storage 的并行执行引擎,能够在 SQL 级别上弹性利用任意数目的 CPU 来加速分析查询,支持 HTAP 的混合负载场景。

8.png
8.png
openTenBase

https://www.opentenbase.org/

OpenTenBase 是企业级分布式数据库 TDSQL 的社区发行版,包含 OpenTenBase 和 TXSQL 双内核,具备高扩展性、商业数据库语法兼容、分布式引擎、多级容灾和多维度资源隔离等能力,成功应用在金融、医疗、航天等行业的核心业务系统。一个 OpenTenBase 集群由多个 CoordinateNodes、DataNodes 和 GTM 节点组成。所有用户数据都存储在 DataNodes 中,CoordinateNode 仅包含元数据,GTM 用于全局事务管理。CoordinateNodes 和 DataNodes 共享相同的模式。2023年12月16日,腾讯云将企业级分布式数据库TDSQL的社区发行版 OpenTenBase 正式捐赠给开放原子基金会。

9.png
9.png
OceanBase

https://github.com/oceanbase/oceanbase

OceanBase 是一个金融级原生的分布式关系数据库,始创于 2010 年,并于 2021 年 6 月正式开源。它具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。OceanBase 为现代数据架构打造的开源分布式数据库。兼容 MySQL 的单机分布式一体化国产开源数据库,具有原生分布式架构,支持金融级高可用、透明水平扩展、分布式事务、多租户和语法兼容等企业级特性。

10.png
10.png
TiDB

https://github.com/pingcap

TiDB 是由 PingCAP 公司自主设计、研发新一代数据库,早在 2015 年便已开源。它是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品。

11.png
11.png
GreatSQL

https://greatsql.cn/

https://gitee.com/GreatSQL/GreatSQL

GreatSQL 数据库是一款开源免费数据库,可在普通硬件上满足金融级应用场景,具有高可用、高性能、高兼容、高安全等特性,可作为 MySQL 或 Percona Server for MySQL 的理想可选替换。

AliSQL

https://github.com/alibaba/AliSQL

AliSQL 是阿里巴巴集团开发的 MySQL 分支数据库。它基于 MySQL 官方版本,并进行了诸多功能和性能方面的增强。AliSQL 已在生产环境中证明了其稳定性和高效性。它可以作为 MySQL 的免费、完全兼容、功能增强且开源的替代方案。AliSQL自2016年8月起便是一个开源项目,由阿里巴巴集团的工程师积极开发。此外,它还整合了来自Percona、WebScaleSQL和MariaDB的补丁。

PolarDB-X

https://github.com/polardb/polardbx-sql

PolarDB-X 是一款面向超高并发、海量存储、复杂查询场景设计的云原生分布式数据库系统。其采用 Shared-nothing 与存储计算分离架构,支持水平扩展、分布式事务、混合负载等能力,具备企业级、云原生、高可用、高度兼容 MySQL 系统及生态等特点。

12.png
12.png
Apache Doris

https://doris.apache.org

https://github.com/apache/incubator-doris

Apache Doris 是一款基于 MPP 架构的易用型、高性能实时分析数据库,以其极快的速度和易用性而著称。即使在海量数据下,它也能以亚秒级的响应时间返回查询结果,不仅支持高并发点查询场景,还能支持高吞吐量的复杂分析场景。所有这些都使得 Apache Doris 成为报表分析、即席查询、统一数据仓库和数据湖查询加速等场景的理想工具。在 Apache Doris 上,用户可以构建各种应用程序,例如用户行为分析、A/B 测试平台、日志检索分析、用户画像分析和订单分析。

13.png
13.png
StarRocks

https://github.com/StarRocks/starrocks

StarRocks 是全球速度最快的开放式查询引擎,支持亚秒级即时分析,无论是在数据湖屋内外,都能流畅运行。其平均查询性能比其他常用方案快 3 倍,无需反规范化即可适应您的各种用例,无需迁移数据或重写 SQL。StarRocks 是一个 Linux 基金会项目。

14.png
14.png
TDengine

https://github.com/taosdata/TDengine

TDengine 是一款开源、高性能、云原生、AI 驱动的时序数据库 (Time-Series Database, TSDB)。TDengine 能被广泛运用于物联网、工业互联网、车联网、IT 运维、金融等领域。除核心的时序数据库功能外,TDengine 还提供缓存、数据订阅、流式计算、AI 智能体等功能,是一极简的时序数据处理平台,最大程度的减小系统设计的复杂度,降低研发和运营成本。

Apache IoTDB

http://iotdb.apache.org/zh/

https://github.com/apache/iotdb

IoTDB (Internet of Things Database) 是一款时序数据库管理系统,可以为用户提供数据收集、存储和分析等服务。IoTDB由于其轻量级架构、高性能和高可用的特性,以及与 Hadoop 和 Spark 生态的无缝集成,满足了工业 IoT 领域中海量数据存储、高吞吐量数据写入和复杂数据查询分析的需求。 更多功能请见时序数据库IoTDB:功能详解与行业应用。IoTDB 依赖 TsFile 项目,它是一种专门用于时序数据管理的文件格式。

Nebula

https://www.nebula-graph.com.cn/

https://gitee.com/vesoft-inc/Nebula

Nebula 是一个分布式、可扩展的开源图数据库,擅长处理千亿个顶点和万亿条边的超大规模数据集,公司创始团队来自于 Facebook、阿里巴巴、华为等国内外各大知名公司。

15.png
15.png
MatrixOne

https://github.com/matrixorigin/matrixone

MatrixOne 是业界首个将 Git 风格版本控制引入数据库的产品,同时具备 MySQL 兼容、AI 原生和云原生架构。作为一款 HTAP(混合事务/分析处理)数据库,MatrixOne 采用超融合的 HSTAP 引擎,在单一系统中无缝处理事务型(OLTP)、分析型(OLAP)、全文检索和向量检索等多种工作负载——无需数据迁移、无需 ETL、无需妥协。

16.png
16.png
Milvus

https://github.com/milvus-io/milvus

Milvus是一个专为大规模应用而构建的高性能向量数据库。它能够高效地组织和搜索海量非结构化数据(例如文本、图像和多模态信息),从而为人工智能应用提供支持。Milvus 使用 Go 和 C++ 编写,并实现了 CPU/GPU 硬件加速,从而提供一流的向量搜索性能。凭借其完全分布式且原生于 Kubernetes 的架构,Milvus 可以横向扩展,处理数十亿个向量上的数万个搜索查询,并通过实时流式更新保持数据最新。

SequoiaDB

https://github.com/SequoiaDB/SequoiaDB

SequoiaDB 巨杉数据库是一款分布式文档型数据库,自研的原生分布式存储引擎支持完整ACID,具备弹性扩展、高并发和高可用特性,并以文档型 JSON 的半结构化数据格式为基础,兼容S3对象数据引擎接口,进一步形成Multi-Model多模数据处理能力,可支持跨结构化、半结构化和非结构化的多模数据处理。适用于历史数据平台、全量数据平台、实时数据中台和内容数据管理平台等各类应用场景。

Databend

https://github.com/databendlabs/databend

Databend 是一个开源的Elastic和Workload-Aware现代云数据仓库。Databend 是一款强大的云数仓,专为弹性和高效设计,自由且开源。它是 Snowflake 的开源替代品,也可在云中使用。Databend 使用最新的矢量化查询处理技术,让您可以在对象存储( S3、Azure Blob、谷歌云存储、华为云 OBS或MinIO)上进行超快的数据分析。

17.png
17.png
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-12-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1).开源的目的是什么
  • 2).开源与商业版本的差异
  • 3).开源商业化的路径成立嘛
  • 4).开源项目能上生产吗
  • 观点:项目参差不齐,活跃差异巨大
  • 观点:新兴数据库类型更为活跃
  • 观点:开源协议多样化,商业化考量明显
  • IvorySQL
  • openTeleDB
  • openHalo
  • openGauss
  • PolarDB-PG
  • openTenBase
  • OceanBase
  • TiDB
  • GreatSQL
  • AliSQL
  • PolarDB-X
  • Apache Doris
  • StarRocks
  • TDengine
  • Apache IoTDB
  • Nebula
  • MatrixOne
  • Milvus
  • SequoiaDB
  • Databend
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档