尊敬的各位委员：
在 2025 年 2 月 25 日，我们于北京成功举办了第一次联合例会。会议筹备期间，我们广泛收集用户需求，共梳理出 25 条需求信息。会议过程中，大家积极交流探讨，又新增了 12 条需求。经过全体与会人员的共同研讨与审慎评估，最终明确其中 11 条为高优先级需求，并针对每条高优先级需求分别指定了跟踪责任人，以确保相关工作的有效推进。
现将全量需求列表予以公布。后续，我们将每月定期发布需求进展报告，并在理事会上对需求处理情况进行跟踪回顾，保证各项工作透明、有序开展。
在此，衷心感谢各位委员对 openGauss 社区的大力支持！正因为有各位的积极参与和倾心付出，社区才得以蓬勃发展。期待未来我们继续携手共进，推动 openGauss 社区迈向新的高度 。
openGauss 社区
需求类别
需求内容
需求场景
优先级
社区情况反馈
跟踪责任人
资源池化
资源池化方案支持
需要资源池化的方案说明材料支撑
高
资源池化的使用材料可见社区官网；技术讲解材料可会后提供
陈栋
资源池化: 1. 稳定性（研发故障计划ing) 2. 文档 3. GaussDB似乎不同方案，对一下开源4. 用户遇到稳定性问题 (6.0上特性更稳定）
高
6.0.0资源池化商用版本发布，涵盖189种故障模式库，97%手动可恢复，80%可自动恢复，RAC多写方案在下次UC明确技术路径：
1.云原生开源路径探索
2.基于社区开源的参天实现多写往前演进
熊小军
高可用
对于CM软件在高可用方面进一步提升，在各种异常场景下都能恢复，比如5个节点内，本中心已经丢失2节点，结合同步策略，建议从同城中心选主。
多数据中心（AZ）场景下的容灾架构，当前AZ三个DN。当两个DN故障时，仍能优先从本AZ中选取主
高
当前支持AZ级优先级选主，需设置选主优先级
熊小军
CM丢失3节点后，如何快速从剩余2节点中找到主节点，提高用户的灾备响应能力。
多数据中心（AZ）场景下的容灾架构，当前AZ三个DN。当三个DN全部故障时，如何容灾切换到其他的AZ选取
高
如果是5节点，挂了3个，剩下2个不满足多数派，无法自动选主，需手动强起；
熊小军
双活方案支持
大概率是双集群容灾方案支持
低
社区支持通过发布订阅的方式实现异地双活；也支持双集群实现异地容灾
-
优化CM，能够支持单独切换、启停功能
高可用场景下DN级别的灵活维护能力
低
当前支持CM暂停集群管理功能，也支持对单个DN的启停切换
-
两地三中心，支持双写场景（目前社区说两地写有问题，数据一致性需要根据实际处理）
采用两地部署，两地写（逻辑复制）时能够保证数据一致性
低
当前通过发布订阅实现异地双活，提供用户自定义的冲突解决机制：当订阅端同步数据时遇到主键或唯一键冲突时，数据库通过参数配置进行报错、保留本地或者应用远端。
-
版本升级
针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。
跨大版本升级的易用性、平顺性
高
社区支持跨大版本升级，如3.0.0->6.0.0，当前社区文档版本升级路径显示不支持从3.0->6.0的升级，需要刷新
熊小军
对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。
数据库完全不停机情况下的小补丁升级
高
社区今年规划了热补丁升级能力
朱芳芳
针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。
跨大版本升级的易用性、平顺性
低
社区支持跨大版本升级，如3.0.0->6.0.0
-
对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。
数据库完全不停机情况下的小补丁升级
低
社区今年规划了热补丁升级能力
-
向量数据库
有向量化引擎要求，目前引入了Rust编写的面向向量的搜索引擎Qdrant，openGauss需要在7.0版本下DataVec能使用
大概率是openGauss的datavec对客户当前已使用的Qdrant相关功能的兼容或替换
高
当前社区7.0DataVec版本具备Qdrant完整对标/替换能力，后续单独与国能对接。
阙鸣健
内核
高并发（10k甚至2-3k）：物理机资源高（cpu等），抖动。业务使用随便.
高
大概率是issue，结合移动现网后续跟进解决
李居隆
行存压缩
民生、广州汇智
高
25年明确商用交付，当前方案开发完成，协同海量版本测试中，同时与民生对接后续落地计划
李标
WAL回放性能
高
25年已规划
阙鸣健
日志和数据库状态都只能omm用户看，我们想普通用户也能查? 不能hardcode omm
高
熊小军
兼容性
增加informix的兼容性
客户从informix迁移到openGauss，希望有更好的兼容性
低
Informix迁移社区暂无规划，目前可通过恩墨的mtk工具完成迁移
-
信创改造要求，需逐步替换国外开源数据库MySQL和PGSQL，有Oracle迁移需求，暂无实际的项目计划；
通用性国外数据库兼容性场景
低
对MySQL已支持常用语法100%兼容；Oracle通过使能伙伴完成全量语法50%兼容，今年会进一步增加兼容度；PG语法的兼容性今年暂无规划，后续通过DBV、高校合作项目补齐。
-
针对其他数据库迁移到oG，比如PG，提供语法兼容和迁移方面的规划和工具。
从pg迁移到og的兼容性、迁移工具的支持
低
PG的迁移工具已在实现中，预计630交付
-
工具
异构数据库迁移工具，目前能支持MySQL数据迁移和PGSQL迁移，其他商用数据库支持，比如达梦，Oracle等；
在企业进行数据库系统迁移或整合时，支持将数据从原有的业务数据库如MySQL、PostgreSQL、达梦或Oracle迁移至openGauss，以确保业务的连续性和数据的完整性。
低
社区已支持mysql迁移，已规划对pg的迁移；对oracle的迁移已在24年年初由南大贡献；对其他国产数据库如达梦的迁移，建议DBV伙伴来实现
-
数据库监控平台工具，目前主从监控待引入datakit工具，短信和邮箱报警正在开发，需要监控看板页面，支持运行中的sql语句级别的审计功能。
datakit工具能力
低
当前datakit不支持审计，后续规划实现
-
短信或邮件报警 ，看板监控（社区datakit这些功能已实现，待今年落地国能）
社区datakit工具在国能短信、邮件报警，看板监控场景使用
低
Datakit已支持短信和邮件通知，已提供配置服务的入口
-
openGauss GCC编译工具需适配操作系统自带的GCC和依赖工具，不再独立一套编译工具
企业服务器和操作系统种类多，希望减少所需适配内容
低
不同OS的gcc版本可能不一致，待分析是否完全采用OS的
-
希望社区在AI for DB的领域，对DBmind进一步开源和推广，促进数据库更加智能化。
DBmind重点发展和推广
低
需要高斯回答
-
适配
基于信创桌面系统的数据库和客户端链接工具，需要兼容UOS；
操作系统适配
低
当前社区无规划适配UOS桌面系统
-
版本升级
针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。
跨大版本升级的易用性、平顺性
低
社区支持跨大版本升级，如3.0.0->6.0.0
-
对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。
数据库完全不停机情况下的小补丁升级
低
社区今年规划了热补丁升级能力
-
驱动
1. 支持基于C# ADO.NET框架的数据库驱动程序实现
需要支持.Net开发语言开发项目
低
社区支持.NET，后续需要催熟、官网正式发布
-
2. 支持基于EntityFramework Core ORM框架的数据库提供程序实现
低
-
PHP语言下实现连接池代理，在单个连接查询下延迟大；
PHP语言下的连接池代理
低
是需要PHP驱动支持连接池代理？目前可采用PgBouncer
-
分布式
需要构建分布式事务能力
能够支持分布式节点
低
目前社区暂无分布式数据库规划，可采用南大通用的分布式方案
-
其他
社区上数据库内核及周边工具较多，掌握不容易，有条件的话可以赋能
国产数据库资料相对较少，上手门槛高
低
资料优化；内核和工具直播赋能
-
优化官方手册中描述（有些GaussDB描述或特性，在openGauss中并没有，但是文档和实际环境中还是存在）
修正openGauss中不支持的特性，避免误导用户
低
资料优化
-
文档结构还需要进一步清晰，建议尽量合并成一个整体的文档（大的方面可以分为运维和开发类），通过合适的导航和搜索以及链接方式，精确定位到用户关心的问题。当前文档多而散的模式，使用上反倒不方便。
文档结构、导航希望更加合理
低
资料优化
-
进一步提高官方文档的质量，文档内容较多，部分信息冗余，部分文档解释模糊，甚至解释不准确，用户无法完全理解，上生产操作前需要反复验证。
文档内容质量提升，包括信息冗余、解释模糊、解释不准确、用户可读性差的问题。上生产操作前需要反复验证。
低
资料优化，同时建议用户遇到问题可先直接提issue反馈
-
监控：社区再完善一点.
低
视图/监控部分规划：轻量级锁跟踪、全链路跟踪、视图可视化等25年陆续交付。
-
AI4DB: 移动已经在用，还挺不错（From DBA）, 训练问题：数据安全
低
DBMind使用情况和问题后续单独组织会议对齐-沈金伟
-
分区表：索引问题？不确定具体问题，线下讨论。
低
分区表性能优化（3000+分区场景，TPCC性能损耗小于30%）
-
