WeKan 与 FerretDB 完全指南MongoDB 兼容层的 v1 五后端、v2 部署与一致性验证【免费下载链接】wekanThe Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan项目地址: https://gitcode.com/GitHub_Trending/we/wekanFerretDB 用 MongoDB 线协议对外通信、把数据存进 SQLite / PostgreSQL / MySQL / MariaDB / SAP HANA 等其他东西使得 WeKan 无需任何改动即可运行其上。本文以 docs/Databases/FerretDB/ 文档为主体系统讲解 FerretDB v1 与 v2 的区别、五个后端的选型与启动方式、directConnectiontrue的来龙去脉、OpLog 轮询机制、跨后端一致性测试以及 FerretDB 2 PostgreSQL 的完整安装步骤读完即可自行部署并排查常见启动故障。FerretDB 在 WeKan 中的角色透明代理式存储WeKan 只连接mongodb://ferretdb:27017/wekan?directConnectiontrue对身后真正承载数据的数据库一无所知。FerretDB 负责讲 MongoDB 的协议、存别的数据库因此 WeKan 可以完全不加修改地跑在它之上。这也是 WeKan 文档中反复强调的一句话FerretDB speaks the MongoDB wire protocol and stores the data in something else, so WeKan runs unchanged on top of it.需要特别注意的是 URL 中的directConnectiontrue不是装饰参数。如果去掉它MongoDB 驱动会跟随 FerretDB 的副本集握手去连接 FerretDB 实际监听的通配地址导致整个栈无法启动对应 issue #6582详见下文 为什么 URL 必须带 directConnectiontrue。在 WeKan 的数据库选型中docs/Databases/README.md 将数据层划分为五类默认的 FerretDB v1、PostgreSQL-only 的 FerretDB 2、MongoDB 本体、WeKan 自身的 schema 迁移体系以及已停止开发的 ToroDB。默认数据库是 FerretDB v1 的嵌入式 SQLite——一条docker compose up -d即可启动连独立的数据库服务器都不需要。两个版本两个产品v1 与 v2 的本质差异FerretDB v1 与 FerretDB 2 虽然同名但是两款不同的产品。官方文档用一张表直接划清界限目录版本存储目标1FerretDB v1即 wekan/FerretDB 分支——WeKan 的默认数据库SQLite嵌入式、PostgreSQL、MySQL、MariaDB、SAP HANA2FerretDB 2上游版本仅 PostgreSQL DocumentDB 扩展上游在 v2 中砍掉了除 PostgreSQL 外的所有后端。WeKan 保留 v1 分支有两条理由嵌入式 SQLite 让 WeKan 安装完全自包含——不需要任何数据库服务器它是 MongoDB 没有服务器构建的平台上的默认数据库ppc64le、s390x 和 riscv64。也就是说在这三个 CPU 架构上FerretDB v1 SQLite 是唯一能跑起 WeKan 的数据库路径。FerretDB v1 的五个后端如何选型与状态界定1/README.md 给出了五个后端及各自的 compose 文件与成熟度状态后端Compose 文件状态SQLite嵌入式docker-compose.yml默认已确认可与 Meteor 3 配合工作PostgreSQLdocker-compose-ferretdb-v1-postgresql.yml已确认可与 Meteor 3 配合工作#6509MySQLdocker-compose-ferretdb-v1-mysql.yml实验性MariaDBdocker-compose-ferretdb-v1-mariadb.yml实验性SAP HANAdocker-compose-ferretdb-v1-sap-hana.yml实验性实验性的含义写得很明确代码完整到能运行range /$in下推pushdown和 OpLogts索引都已就位但从未像 SQLite 那样用集成测试套件对真实服务器做过验证。文档给出的建议是这三个后端适合尝试不适合押注生产。各 compose 文件只差数据库其他完全一致这些文件之间唯一的区别就是数据库同一个 WeKan 镜像、同一套设置、同样的注释。这意味着从任何一个文件学到的配置项在其余文件中同样适用。这一约束由 tests/dockerComposeBackends.test.cjs 守护——它会把每个文件的 WeKan 服务与默认文件逐行比对。启动命令每个 compose 文件顶部都写明了启动方式。默认文件无需-fdocker compose up -d其余后端需要显式指定文件名docker compose -f docker-compose-ferretdb-v1-postgresql.yml up -d docker compose -f docker-compose-ferretdb-v1-postgresql.yml logs -f docker compose -f docker-compose-ferretdb-v1-postgresql.yml down./build.sh的Docker菜单提供同样的后端列表Windows 下build.bat亦然。默认栈的服务拓扑从 docker-compose.yml 可以看到默认栈的完整结构只有一个ferretdb服务加一个wekan服务。ferretdb服务本身不是 FerretDB 镜像而是一个精简 Debian 容器debian:bookworm-slim启动时若缺少 curl先apt-get install curl ca-certificates通过curl -fsSIL跟随https://github.com/wekan/FerretDB/releases/latest的重定向解析出最新 release 号按dpkg --print-architecture获取本机架构ppc64el归一化为ppc64le只下载对应的ferretdb-arch二进制及其.sha256sum校验 SHA-256 通过后才 chmod x 并 mv 到/data/bin/ferretdb以--handlersqlite --sqlite-urlfile:/data/files/db/ --listen-addr0.0.0.0:27017 --telemetrydisable --log-levelerror启动。健康检查用bash -c /dev/tcp/127.0.0.1/27017探测 27017 端口start_period: 30s覆盖首次下载二进制的时间wekan服务通过depends_on: condition: service_healthy等待 FerretDB 真正就绪避免浏览器端出现 Connection reset by peer。二进制如何到位按架构分发的 release 资产与版本锁定所有 v1 compose 文件都不用 FerretDB 镜像而是从最新 wekan/FerretDB release 下载对应架构的ferretdb-arch二进制缓存在卷上并运行。想要固定版本设置FERRETDB_RELEASEdownload/v1.24.2compose 文件中默认值为${FERRETDB_RELEASE:-latest/download}即默认跟随最新发布一旦设置了具体版本容器启动脚本会比较ferretdb.release缓存文件中的版本号不一致就重新下载替换。十七个跨架构二进制这些二进制共构建 17 个全部从一个 checkout 以CGO_ENABLED0交叉编译十个 Linuxamd64、arm64、armhf、armv6、armel、i386、ppc64le、s390x、riscv64、loong64三个 Windowswin64、win-arm64、win32两个 macOSmac-amd64、mac-arm64两个 FreeBSDfreebsd-amd64、freebsd-arm64。其中 32 位 ARM 的三种是三个不同构建而非同一构建的别名armhf对应GOARM7armv6对应GOARM6面向树莓派 1 与 Zeroarmel对应GOARM5软件浮点面向真正的 ARMv5。ferretdb-arch二进制被打进每一个WeKan 包bundle中并在 MongoDB 不发布服务器的平台上ppc64le、s390x、riscv64、i386、armv6、armhf成为唯一可用的默认数据库。此外还围绕这些二进制构建了多架构镜像wekanteam/ferretdb、quay.io/wekan/ferretdb、ghcr.io/wekan/ferretdb基于FROM scratch因此覆盖了全部 Linux 架构包括 WeKan 镜像无法触及的linux/arm/v6与linux/loong64详见 Docker CPU platforms。关于 SAP HANA其 handler 位于ferretdb_hana构建标签之后发布的二进制均带此标签构建所以--handlerhana可用若在别处以不带该标签的方式自行构建则会得到 unknown handler 的报错。OpLogv1 模拟副本集与默认轮询模式FerretDB v1 可以模拟副本集--repl-set-namers0因此 Meteor理论上可以 tail OpLog 而不是轮询。但实际约束是SQLite 后端上 tail OpLog 会让 FerretDB 的 CPU 被钉死并阻塞加载#6503其他后端上的 OpLog 行为未经验证。因此每个 compose 文件默认轮询polling且METEOR_REACTIVITY_ORDERoplog,polling与MONGO_OPLOG_URL都被注释掉。文档特别警告仅仅设置MONGO_OPLOG_URL就会开始 tail无论 reactivity order 如何设置#6498。FerretDB 无论哪个版本都没有 MongoDB 的 change streams。这与 docs/Databases/MongoDB/Oplog-Configuration.md 中 MongoDB 副本集方案形成对照——需要 change-stream 级响应式能力时应改用 docker-compose-mongodb-v7.yml。为什么 URL 必须带directConnectiontrue这是 FerretDB 部署中最容易踩的坑文档用一个真实报错完整还原了故障链。去掉该参数后首次启动报错MongoServerSelectionError: connect ECONNREFUSED 0.0.0.0:27017 reason: TopologyDescription { type: ReplicaSetNoPrimary, servers: Map(1) { 0.0.0.0:27017 [ServerDescription] }, setName: rs0, ... }0.0.0.0没有出现在任何 compose 文件里——它是 FerretDB 自己的listen 地址是服务器塞给驱动的。故障机理ferretdb服务以--repl-set-namers0运行见上节因此 FerretDB 把hello握手应答为一个单成员副本集并把hosts、me、primary字段填成--listen-addr的值——通配地址0.0.0.0:27017非直连模式的 MongoDB 驱动把这种应答视为进行副本集发现的邀请它采用服务器通告的成员列表丢弃了自己拿到的 seed因为服务器报告的地址与拨号地址不一致于是mongodb://ferretdb:27017被解析成0.0.0.0:27017在wekan-app容器内这指向容器自身——那里没有任何服务在监听于是ECONNREFUSED而 compose 文件从未被改动过。加上directConnectiontrue后驱动只停留在给定的主机上并跳过发现。文档记录了针对 FerretDB v1.49.0 与包内驱动实测的拓扑结果MONGO_URL驱动最终得到的拓扑mongodb://localhost:27017/wekanReplicaSetWithPrimaryservers0.0.0.0:27017——seed 被丢弃mongodb://localhost:27017/wekan?directConnectiontrueSingleserverslocalhost:27017该参数没有其他代价握手仍会报告setName: rs0而这正是 Meteor 决定是否 tail OpLog 时唯一检查的东西因此MONGO_OPLOG_URL...?replicaSetrs0directConnectiontrue照常工作沿用 #6480/#6481 的结论。这条规则仅适用于 FerretDB。MongoDB 的 compose 文件连接的是真实副本集其成员配置了可解析的域名因此保留纯replicaSetrs0绝不能加上directConnection。一致性验证db-conformance 测试如何证明五个后端回答相同FerretDB v1 要把一条 MongoDB 查询翻译成五种不同的 SQL 方言。{n: {$gt: 5}}能在 PostgreSQL、MySQL、MariaDB、SAP HANA 上运行说明不了什么——是否与 SQLite 返回相同的文档、相同的顺序才是决定一个后端能否托付看板数据的关键。1/Conformance.md 描述的测试可一键运行./build.sh # - Tests - All databases (sequential) ./releases/db-conformance.sh # 同一件事不需要菜单build.bat在 Windows 上也有相同入口通过 bash 运行同一脚本。测试流程四步从源码构建 FerretDB v1若FerretDB子目录不存在则从gitgithub.com:wekan/FerretDB克隆HTTPS 兜底更新后通过其自身的build.sh构建——测试针对的是最新代码而非下载的 release挑选本 CPU 能实际运行的数据库用docker manifest inspect询问镜像是否有该架构的构建。arm64 上是 SQLite、PostgreSQL、MySQL、MariaDBppc64le 和 s390x 上是 SQLite、PostgreSQL、MariaDBriscv64 上是 SQLite、PostgreSQL逐个运行查询目录刻意串行执行因为所有后端共用同一个 FerretDB 端口被测数据库不应与其他三个抢 CPU 和磁盘以 SQLite 为参照比对答案。100 个用例、15 组查询目录来自 FerretDB v1 自身源码而非 MongoDB 手册——目的是覆盖这个FerretDB 实现的功能比较/逻辑/元素/求值/数组/位运算/嵌套路径操作符投影含$slice、$elemMatch、排序、skip/limitcount、distinct聚合$match、带全部累加器的$group、$project、$addFields、$facet、$bucket、$lookup、$replaceRoot、$sortByCount全部更新操作符、findAndModify、replaceOne、删除命令索引的创建/列举/唯一性/删除capped collectionsOpLog 存在的基础explain、collStats、dbStats、listCollections、buildInfo。种子数据刻意刁钻null、缺失字段、负数、零、空数组、文档数组、混合大小写字符串——干净的数据会让错误的翻译蒙混过关。相同的定义答案先归一化类型显式化、键顺序排序再逐字节比对因此文档顺序也计入差异排序返回了正确的文档但顺序不同就是差异而非细节。仅三类用例放宽比较并在报告中注明explain计划在不同引擎上天然不同只比较形状collStats/dbStats是存储引擎有权给出不同答案的尺寸指标只需能回答。其余必须完全一致。两个后端以相同方式失败是对某一局限的共识而非差异一个能答而另一个失败才是差异。端口隔离与产物测试中 FerretDB 监听37017避开 27017那里是 dev server 数据库和 compose 发布 FerretDB 的位置其数据库服务器发布在35432而非惯用的 5432/3306。两者默认被占用时会自动后移也支持自定义WEKAN_CONFORMANCE_PORT47017 WEKAN_CONFORMANCE_DB_PORT45432 ./releases/db-conformance.sh容器按运行时间命名wekan-conformance-db-datetime不会干扰docker compose up启动的wekan-postgres、wekan-ferretdb容器。结果落在../log/datetime/文件内容db-conformance-build.log克隆、更新、构建 FerretDB 的日志db-conformance-backend.json该后端给出的每一条答案db-conformance-backend.log该后端的数据库与 FerretDB 输出db-conformance-report.md一致之处与每个不一致用例db-conformance-summary.txt每个后端一行已运行、已跳过或原因脚本在某个后端与参照不一致时以非零码退出。SAP HANA 默认不参与除非设置WEKAN_CONFORMANCE_HANA1——其镜像仅 amd64、约需 16 GB 内存和几十 GB 磁盘还要接受 SAP 许可不适合因随手点了个菜单项就启动。相关目录为 tests/dbConformance/。其他数据库CPU 覆盖矩阵与新增后端的门槛FerretDB v1 分支存在的根本原因是WeKan 能跑在所有 Node.js 支持的 CPU 上amd64、arm64、ppc64le、s390x、riscv64而 MongoDB 对其中大部分不发布服务器。1/Alternatives.md 从注册表 manifest 实测2026-07-28给出了镜像的 CPU 覆盖镜像amd64arm64ppc64les390xriscv64其他postgres:1817、16 同✓✓✓✓✓386, armv5, armv7mariadb:1211.8 LTS 同✓✓✓✓✗—cockroachdb/cockroach✓✓✗✓✗—mysql:98.4 LTS 同✓✓✗✗✗—mongo:8✓✓✗✗✗windows/amd64ferretdb/ferretdb上游 v2✓✓✗✗✗—wekanteam/ferretdb本分支✓✓✓✓✓386, armv5, armv7,loong64两个结论值得读两遍PostgreSQL 是这里唯一广泛可移植的数据库服务器同时覆盖 ppc64le、s390x、riscv64这也是 docker-compose-ferretdb-v1-postgresql.yml 在需要独立数据库服务器时成为推荐选项的原因MongoDB 本身只有 amd64 arm64上游 FerretDB 2 亦然因此在 ppc64le、s390x、riscv64、loong64 上除本分支的嵌入式 SQLite 外别无选择。数据库家族与缺口PostgreSQL-wire 系PostgreSQL、CockroachDB、YugabyteDB、TimescaleDB、openGauss、Greenplum无需写代码jackc/pgx已能连接只差用--handlerpostgresql对其 SQL 方言跑一次集成测试MySQL-wire 系MySQL、MariaDB、Percona、TiDB、SingleStore同样无需写代码。MariaDB 是原样运行的范例——一切正常唯独缺少函数式 key parts导致 OpLogts索引静默建不起来直到本分支加入GENERATED ... STORED列兜底企业级 SQLSQL Server、Oracle、IBM Db2各需整套新后端。SQL Server 与 Oracle 有纯 Go 驱动microsoft/go-mssqldb、sijms/go-oraDb2 的go_ibm_db依赖 cgo而 cgo 正是九架构构建不能有的东西嵌入式/文件型DuckDB、libSQL/Turso先解决纯 Go 驱动问题再写整个后端列式/分析型ClickHouse、StarRocks、Doris缺少按行的UPDATE/DELETE、_id唯一性、capped collections——这是工作负载形态的错配不是工作量的问题键值/宽列Cassandra、ScyllaDB、FoundationDB、TiKV没有可翻译的 SQL索引、过滤、连接都要在 FerretDB 内实现——那不是后端是数据库本已 MongoDB 兼容MongoDB、DocumentDB、Cosmos DB什么都不缺WeKan 直接对接无需 FerretDB——docker-compose-mongodb-v7.yml 正是如此只是这些平台在 ppc64le、s390x、riscv64、loong64 上没有成员。新后端的工作量一个后端约1700–3600 行 Gopostgresql3637、mysql3497、sqlite3328、hana1716不含测试包含六件套纯 Go 驱动、internal/backends三个接口Backend / Database / Collection均不得为 stub、元数据注册表每后端一张_ferretdb_database_metadata表、翻译实际用到的 SQL 特性JSONB 路径提取、包含与jsonb_typeof、CREATE SCHEMA、表达式索引、可解析的EXPLAIN、information_schema、支撑 capped collection/OpLog 的_ferretdb_record_id排序列、BSON 类型间排序等 MongoDB 语义、以及对真实服务器的集成验证。下推规则是最易在测试注意不到的地方出错的一环下推过多会静默丢文档。文档给出的优先级是先验证 MySQL/MariaDB/SAP HANA有代码无证明比任何新后端都便宜还能摘掉实验性标签再尝试 PostgreSQL-wire 数据库CockroachDB 带来 s390x最后才考虑新后端。已验证的 SQLite 恢复与低负载维护设计1/Verified-Recovery.md 记录了一个已实现的设计状态ImplementedOwner: xet7覆盖所有使用 FerretDB v1 SQLite 的 WeKan 启动路径以及 snap 的 MongoDB→FerretDB 迁移。恢复材料存放在 SQLite 目录下方的.recovery/子目录中不依赖任何无关的家目录、临时目录或外部服务db/wekan.sqlite db/.recovery/latest/wekan.sqlite.gz db/.recovery/latest/manifest.json db/.recovery/previous/wekan.sqlite.gz db/.recovery/previous/manifest.json db/.recovery/migration-source/manifest.json db/recovery-events.jsonl db/.recovery/maintenance-request.jsonmanifest 记录压缩前后字节数、两种形式的 SHA-256、创建时间、源文件身份、原因与 schema 版本最后写入并以原子重命名发布没有完整有效 manifest 的目录不构成恢复候选。快照的不变量包括只对静止状态的数据库做快照、写前检查可用空间按活库大小 可配置安全余量不假设压缩率、经暂存目录流式 gzipSHA-256 后原子发布、绝不拿损坏/不完整/不可验证的快照覆盖已验证世代、恢复时先验证解压校验和与大小再原子替换wekan.sqliteWAL/SHM 文件仅在替换就绪后删除所有决策与失败都追加进 recovery JSONL。启动恢复按顺序校验活库 SQLite → 最新快照 → 上一份快照检查器用与发布版 FerretDB 相同的 SQLite 库执行PRAGMA quick_check且不起网络服务。恢复决策表活库结果自动动作健康正常启动到期且安全时创建已验证快照损坏latest 有效恢复 latest复检后启动损坏latest 无效、previous 有效恢复 previous复检后启动损坏无有效快照、保留的 MongoDB 源可读在暂存区重跑迁移、比对集合证据后原子接管损坏无已验证来源保持维护模式并报告manual-required绝不在已知损坏的文本数据上启动检查不可用/未知不猜测不覆盖报告缺失的检查器并按配置的保守策略执行MongoDB 迁移恢复以原始 MongoDB 文件为最终恢复源迁移前记录源证据文件 mtime/大小、可读时的各集合计数/最新时间戳与进度检查点的校验和中断后的恢复仅在证据与检查点哈希仍匹配时进行否则隔离部分 SQLite 文本数据并从头重迁迁移完成以目标证据覆盖源证据、目标通过 SQLite 完整性检查、且已发布首份已验证快照为准。低负载调度依赖cpuMonitor维护的有界滚动采样窗口时间、系统 CPU、负载均值、当前 WeKan 活动非紧急的 CPU 重活请求维护租约仅在连续样本低于低负载阈值后执行同一时间只允许一个重活任务分块让步、CPU 上升即推迟。快照压缩、校验和验证、迁移比对、历史链审计等均走该租约。篡改证据方面变更历史行构成按看板划分的 SHA-256 链覆盖不可变内容、操作者、时间与前驱undo/redo 前验证行、前驱与无分叉后台审计以有界批次检查每条链缺少文件、尺寸变化、签名基线无效、校验和变化都会上报到 Admin Panel → Problems → Security。测试通过临时 SQLite 目录与注入的命令/文件系统故障覆盖健康快照/恢复、latest→previous 回退、损坏 gzip、错误校验和、截断 manifest、空间不足、暂存写入中断、迁移期间源证据变化、无可用源、高 CPU 推迟、租约串行化与恢复事件导入。FerretDB 2 PostgreSQL逐步安装与 v1 的一容器自包含不同FerretDB 2 需要 PostgreSQL 17 DocumentDB 扩展。2/PostgreSQL.md 给出了完整步骤也可直接使用现成 compose 文件docker compose -f docker-compose-ferretdb-v2-postgresql.yml up -d它运行两个容器——ghcr.io/ferretdb/postgres-documentdb与ghcr.io/ferretdb/ferretdb:2——而 FerretDB v1 只跑一个或使用独立 SQL 服务器时跑两个。原生安装路径WeKan 源码构建备用sudo npm install -g n Meteor 2.16 等工具链后git clone --branch main --depth 1 https://github.com/wekan/wekan.git cd wekan sudo apt update sudo apt install -y build-essential gcc g make git curl wget \ p7zip-full zip unzip unp npm sudo npm install -g n export N_NODE_MIRRORhttps://github.com/wekan/node-v14-esm/releases/download sudo -E n 14.21.4 sudo npm -g install mapbox/node-pre-gyp sudo npm -g install meteor2.16 --unsafe-perm export PATH$PATH:$HOME/.meteor meteor npm install production meteor build .build --directory --platformsweb.browserPostgres 17 DocumentDB通过 Pigsty 仓库sudo bash -c curl -fsSL https://repo.pigsty.io/pig | bash pig repo add pgsql -u pig ext install pg17 pig ext install documentdb在/etc/postgresql/17/main/postgresql.conf设置shared_preload_libraries pg_cron, pg_documentdb, pg_documentdb_core编辑/etc/postgresql/17/main/pg_hba.conf把127.0.0.1/32与::1/128主机行上的scram-sha-256换成trust然后sudo service postgresql restart。FerretDB下载并安装 deb示例版本 v2.7.0在/etc/systemd/system/ferretdb.service中填入数据库账号密码EnvironmentFERRETDB_POSTGRESQL_URLpostgres://ferret:DB_PASSWORD_GOES_HERE127.0.0.1:5432/postgres然后sudo systemctl enable ferretdb.service与sudo service ferretdb start。初始化数据库以 postgres 身份进入 psqlCREATE ROLE ferret WITH PASSWORD DB_PASSWORD_GOES_HERE; CREATE DATABASE ferretdb; GRANT ALL PRIVILEGES ON DATABASE ferretdb TO ferret; ALTER ROLE ferret WITH LOGIN; CREATE EXTENSION documentdb CASCADE; GRANT USAGE ON SCHEMA documentdb_api to ferret; GRANT USAGE ON SCHEMA documentdb_core to ferret; GRANT USAGE ON SCHEMA documentdb_api_internal to ferret; GRANT USAGE ON SCHEMA documentdb_api_catalog to ferret; GRANT INSERT ON TABLE documentdb_api_catalog.collections to ferret; GRANT ALL ON SCHEMA documentdb_data to ferret; GRANT documentdb_admin_role to ferret;启动 WeKan命令行或 SystemD 均可核心环境变量是MONGO_URLmongodb://ferret:DB_PASSWORD_GOES_HERE127.0.0.1:27017/wekan配合ROOT_URL、WITH_APItrue、WRITABLE_PATH等。SystemD 方案通过/etc/default/wekan提供环境、以boards用户运行node main.js前面可加 Caddy 做 TLS。文档附带的硬件提示npm 安装 meteor 阶段需至少 3 GB 内存384 MB 会崩溃meteor build阶段需至少 4 GB并且准备好阅读 build.sh 才能真正跑起来。小结与延伸阅读FerretDB 让 WeKan 在数据库层获得了双重自由架构自由嵌入式 SQLite 实现零依赖自包含与平台自由覆盖 MongoDB 缺失的 ppc64le、s390x、riscv64 等 CPU。部署时应记住三条硬规则连接串必须带directConnectiontruev1 默认轮询、设置MONGO_OPLOG_URL即会触发 tailv1 与 v2 是不同产品五个后端的成熟度不同。深入阅读可继续查看FerretDB v1 五后端详解 与 一致性测试说明其他数据库的可行性分析 与 SQLite 恢复设计FerretDB 2 安装指南MongoDB 方案与 OpLog 说明测试入口releases/db-conformance.sh 与 tests/dockerComposeBackends.test.cjs【免费下载链接】wekanThe Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan项目地址: https://gitcode.com/GitHub_Trending/we/wekan创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考