Tigris：下一代无服务器数据库

先问一个问题：你用过 MongoDB 吗？如果用过，那你大概率也经历过分片集群配到崩溃、半夜被扩容告警叫醒的日子。

说实话，我第一次接触 Tigris 的时候，脑子里就一个想法------这不就是我一直想要的 MongoDB 替代品吗？完全兼容 MongoDB 协议，却自带无服务器架构和全球分布式能力，不用写一行分片配置。

引用

传统数据库运维有三座大山：扩缩容、高可用、全球部署。

MongoDB 虽然好用，但上了生产就得面对这些问题。分片键选错了，数据倾斜，热点问题把你折磨得死去活来。想做多区域部署，光是网络规划和副本集配置就能写一本操作手册。

更扎心的是成本。你得为峰值流量预留资源，可大部分时间这些机器都在摸鱼。根据 Flexera 2024 云状态报告，企业自建数据库的平均资源利用率只有 35% 左右。剩下的 65%，都是白白烧掉的钱。

开发者真正想要什么？一个能自动伸缩、按用量付费、全球部署还不用自己操心的数据库。Tigris 就是冲着这个来的。

Tigris 到底怎么做到的

Tigris 的核心架构分三层，每一层都值得细说。

存储层：FoundationDB 打底

Tigris 选择 FoundationDB 作为底层存储引擎，这个决策非常聪明。FoundationDB 是 Apple 开源的分布式 KV 存储，在金融和游戏中用了几十年，事务一致性经过充分验证。它自带确定性模拟测试框架，代码质量极高。

Tigris 把文档数据序列化后存入 FoundationDB，所有 CRUD 操作最终都转化为 KV 操作。这意味着 Tigris 天然继承了 FoundationDB 的 ACID 事务、自动分片和故障转移能力。

计算层：无服务器查询引擎

查询层是 Tigris 自己写的，用 Rust 开发。Rust 的选择也很讲究------零成本抽象、内存安全、极致性能，做数据库再合适不过。

查询引擎收到 MongoDB 协议的请求后，先做查询解析和优化，然后并行地从 FoundationDB 读取数据，在内存中完成过滤、排序、聚合，最后按 MongoDB 协议格式返回。

因为是计算存储分离架构，查询引擎可以独立扩缩容。流量上来时自动拉起更多实例，流量下去时自动回收。你完全不用管。

控制面：全局元数据管理

Tigris 的控制面负责数据库、集合、索引的创建与管理，以及多区域数据同步策略。

它把数据库抽象成"项目"（Project），每个项目可以关联多个"分支"（Branch）。分支概念借鉴了 Git，你可以给数据库创建开发分支、测试分支，改完后再合并到生产。这个设计对 CI/CD 流程极其友好。

对比分析：Tigris vs MongoDB Atlas vs PlanetScale

维度	Tigris	MongoDB Atlas	PlanetScale

|------|-------------|----------------|------------|
| 开源协议 | Apache 2.0 | SSPL | Apache 2.0 |
| 无服务器 | 原生支持 | 有 Serverless 版 | 原生支持 |
| 协议兼容 | MongoDB 协议 | 原生 | MySQL 协议 |
| 全球分布 | 原生多区域 | 需额外配置 | 原生多区域 |
| 分支功能 | 原生 Git 风格分支 | 无 | 数据库分支 |
| 自托管 | 支持 | 企业版支持 | 不支持 |

Tigris 的独特卖点在于：它既兼容 MongoDB 协议（迁移成本极低），又原生支持无服务器和全球部署，同时还完全开源。

MongoDB Atlas Serverless 虽然也免运维，但底层架构还是传统副本集那一套，冷启动延迟较高，而且 SSPL 协议在有些场景下存在合规风险。

PlanetScale 也很优秀，但它绑定了 MySQL 协议。如果你的技术栈是 Node.js / MongoDB 生态，迁移成本会很高。

实践指南：5 分钟上手 Tigris

下面用 Docker 本地跑一个 Tigris 实例，然后用 MongoDB 客户端直接连接。

第一步：拉镜像并启动

bash 复制代码

docker run -d \
  --name tigris \
  -p 27017:27017 \
  tigrisdata/tigris:latest

就这么简单，一个容器搞定。不需要配置副本集，不需要初始化分片，不需要创建用户------Tigris 默认无认证，本地开发直接连。

第二步：用 mongosh 连接

bash 复制代码

mongosh mongodb://localhost:27017

你会看到熟悉的 MongoDB Shell 提示符。但此时连的已经是 Tigris，不是 MongoDB。

第三步：创建数据库和集合

bash 复制代码

use myapp

db.users.insertOne({
  name: "张三",
  email: "zhangsan@example.com",
  age: 28,
  tags: ["python", "rust"]
})

db.users.find({ age: { $gte: 25 } })

增删改查、索引、聚合管道，MongoDB 的 API 基本都能用。Tigris 目前支持 MongoDB 5.0 协议的大部分操作。

第四步：创建索引

javascript 复制代码

db.users.createIndex({ email: 1 }, { unique: true })
db.users.getIndexes()

索引创建也是标准的 MongoDB 语法，背后 Tigris 会自动在 FoundationDB 中建立对应的二级索引。

进阶：多区域部署

Tigris 的生产部署支持多区域数据同步，通过项目配置文件指定区域：

XML 复制代码

# tigris.yaml
name: myapp-prod
regions:
  - aws-us-east-1
  - aws-eu-west-1
  - aws-ap-southeast-1

配置提交后，Tigris 控制面会自动在三个区域部署实例，并建立数据同步通道。写入请求会同步复制到所有区域，读请求就近访问，延迟降到最低。

适用场景

Tigris 特别适合这几类项目：

Serverless 应用：部署在 Vercel / Netlify / Cloudflare Workers 上的应用，配合 Tigris 的无服务器特性，真正做到全栈免运维。
全球多区域 SaaS：用户分布在不同大洲，Tigris 原生多区域同步能显著降低读写延迟。
快速原型与 MVP：不用纠结数据库架构，一个容器/一个云实例就能跑起来，后续无缝扩展到全球。
现有 MongoDB 项目迁移：如果你已经在用 MongoDB，迁移到 Tigris 的成本极低，改个连接串就行。

局限与注意事项

Tigris 目前还在快速迭代中，有几个点需要注意：

事务支持局限在单文档和有限的多文档场景，复杂的跨集合事务还不如 MongoDB 成熟。部分聚合管道的 Stage 尚未完全支持，比如 $lookup 在跨区域场景下可能有性能问题。自托管方案文档还不够完善，生产环境建议优先使用 Tigris Cloud。

总结

Tigris 做对了一件事：它没有重新发明数据库，而是在成熟协议和成熟存储引擎之上，构建了一套真正云原生的无服务器架构。

你得到的是 MongoDB 的开发体验、FoundationDB 的可靠性、以及无需操心的弹性伸缩。这三样东西放在一起，对开发者的吸引力是致命的。

如果你正在选型下一款数据库，或者受够了 MongoDB 的运维负担，值得花一个下午试试 Tigris。

参考资料

GitHub：GitHub - tigrisdata-archive/tigrisdb: Tigris is a globally distributed, multi-cloud object storage service with built-in support for the S3 API. It uses Dynamic Data Placement and Access-Based Rebalancing to deliver low-latency access worldwide --- without the need to manage replication or caching. · GitHub官网：https://www.tigrisdata.com