金仓数据库没有setFeatureCompatibilityVersion命令，因其MongoDB兼容性基于协议层内建能力，不依赖MongoDB版本行为；文档数据统一以JSONB类型存储于关系型引擎，BSON解析与执行在协议层完成转换，无需版本兼容控制，仅需enable_protocol_compat参数开关协议入口。
金仓数据库不提供 MongoDB 的“向前兼容”或“向后兼容”文档设计机制——它压根不依赖 MongoDB 的版本兼容性策略，比如 setFeatureCompatibilityVersion 这类命令在金仓中根本不存在，也不需要。
为什么金仓里没有 setFeatureCompatibilityVersion？
因为金仓的 MongoDB 兼容是协议层内建能力，不是靠模拟 MongoDB 版本行为来实现的。MongoDB 的 setFeatureCompatibilityVersion 是为了解决自身升级过程中数据格式变更带来的降级风险（比如 6.0 → 7.0 后写入的新字段类型无法被旧版读取），而金仓从一开始就没有“MongoDB 内部数据格式”这个概念。
它的文档数据统一以优化后的 JSONB 类型落地到关系型存储引擎中，所有 BSON 解析、索引构建、聚合执行都在协议解析阶段完成转换，不产生 MongoDB 原生的 WiredTiger 存储格式。所以：
– 无需设置兼容版本
– 不存在“降级失败”风险
– 也不支持通过该命令开启/关闭某类特性
金仓中真正影响兼容性的配置项只有 enable_protocol_compat
这个参数控制的是 MongoDB 协议栈是否启用，它才是实际决定“能不能连上、能不能用 mongosh”的开关。其他所谓“兼容性控制”都属于干扰项。
-
enable_protocol_compat=on：监听27017端口，接受标准 OP_MSG 指令，支持 SCRAM-SHA-256 认证 -
enable_protocol_compat=off：完全关闭 MongoDB 协议入口，仅保留原生 SQL 接口 - 该参数修改后需重启数据库生效，不支持动态热加载
注意：enable_protocol_compat 不控制语法支持范围——$lookup、$facet、$vectorSearch 等高级聚合阶段默认全部可用，无需额外开启。
如果你的应用真在 MongoDB 里用了 setFeatureCompatibilityVersion
迁移前要确认两件事：
- 你是否真的启用了 8.3 新增的不可降级特性（如
changeStreamPreAndPostImages）？这类功能在金仓中无对应实现，但也不会报错——因为金仓根本不解析这些元数据字段 - 你的备份文件（
mongodump输出）是否含UUID、Decimal128或自定义MinKey/MaxKey？金仓支持前两者，但对后者仅做透传，不参与查询逻辑
实测中，只要备份时没启用 dryRun: true 或 confirm: false 这类测试参数，金仓就能直接读取 mongorestore 生成的标准 BSON 归档包，无需中间转换。
最容易被忽略的一点：金仓的兼容性边界不在语法或协议，而在事务语义。MongoDB 的多文档事务默认是“会话级快照”，而金仓基于 ACID 强一致模型，session.startTransaction() 调用后所有操作会绑定到底层行锁+MVCC 快照。这意味着某些高度依赖 MongoDB “最终一致性容忍窗口”的老代码，在金仓里可能因锁等待变长而超时——这不是兼容问题，是模型差异。
