前言
从 Django 的避风港走向异步星辰大海
------题记
最近的空闲时间，我折腾了 TechDistill 项目，可以看到近期的公众号推送都是「AI科技日报」，这就是 TechDistill 项目的产物，在每天快速迭代的各类技术新闻中，开发者和技术爱好者往往会面临严重的信息过载。TechDistill 通过聚合多个高质量的技术信息源，并利用 LLM（大型语言模型）进行深度的整理与总结，从而大幅降低用户筛选和阅读的心智负担。
也是在开发新东西的时候，我觉得传统的 Django 方案太重了，FastAPI 的方案虽然简单易用，但我不喜欢这种散装的工具，给人一种混乱、无秩序的感觉，这时候我想起来之前写文章分享过的 LiteStar...
作为一名在 Django 生态浸淫多年的开发者，我一直对 Django 那套全家桶方案心存敬畏：稳定、完善，几乎定义了 Python Web 开发的标准。但随着 Web 迈入异步（Async）时代，尤其是当最近深度体验了 LiteStar 这种追求极致架构与性能的框架后，我意识到是时候在一些 AI 相关的新项目上使用 LiteStar 了，而跳出 Django 生态意味着告别成熟好用的 Django ORM
在现代异步 Web 开发中，ORM（对象关系映射）的选型不再是随框架赠送，而是一场关乎代码整洁度、类型安全和工程上限的深度博弈。
今天，我们就来聊聊目前 Python 异步生态中具有代表性的三个选择：SQLAlchemy 2.0 、Tortoise ORM 和 Piccolo。
参赛选手
SQLAlchemy 2.0：数据库界的工业母机
如果说 Python 数据库领域有一座神庙，那供奉的一定是 SQLAlchemy。在经历了漫长的 1.x 时代后，2.0 版本的发布标志着它正式拥抱了强类型标注和原生异步。
SQLAlchemy 在 GitHub 上拥有 11.7k stars，是 python 生态里 ORM 的第一选择。
- 核心哲学： Data Mapper（数据映射模式）。它将内存中的对象与数据库表结构解耦，给予开发者极高的操作精度。
- 杀手锏： 无敌的生态与 Alembic 迁移工具。
- 槽点： 学习曲线最陡峭，配置略显繁琐。
Tortoise ORM：Django 老玩家的温柔乡
如果你习惯了 Django 那套 Model.objects.filter() 的写法，Tortoise 会让你感到前所未有的亲切。
这个项目到现在也发展了很长时间了，在 GitHub 上有 5.5k+ stars，算是成熟的项目了。
- 核心哲学： Active Record（领域模型模式）。模型本身即包含了数据操作逻辑。
- 杀手锏： 零学习成本（针对 Django 用户）。
- 槽点： 灵活性受限，在大规模复杂查询下显得有些吃力。
Piccolo：来自未来的 Prisma 挑战者
这是一个 GitHub Stars 不算多（约 1.9k），但设计极其惊艳的小众精品。
有点像 TypeScript 生态的 Prisma 和 drizzle 那种感觉。
- 核心哲学： 现代、轻量、类型安全优先。
- 杀手锏： 极具现代感的链式语法和自带的 Piccolo Admin。
- 槽点： 社区生态较小，在生产环境遇到 Bug 时可能需要孤军奋战。
直接上代码
为了直观对比，我们设计一个经典的场景：用户（User）与文章（Post）的一对多关联查询。
建模对比
SQLAlchemy 2.0 强制要求类型标注，对 IDE 极其友好：
python
class User(Base):
__tablename__ = "user"
id: Mapped[int] = mapped_column(primary_key=True)
name: Mapped[str] = mapped_column(String(30))
posts: Mapped[list["Post"]] = relationship(back_populates="user")Tortoise 则是熟悉的味道，几乎 1:1 还原 Django 模型写法。
python
class User(Model):
id = fields.IntField(pk=True)
name = fields.CharField(max_length=30)Piccolo 简洁到了极致，为异步和类型安全而生，语法非常现代。
模型定义直接继承 Table
python
class User(Table):
name = Varchar(length=30)CRUD 操作对比
SQLAlchemy (显式 Session 模式):
python
# Create
async with async_session() as session:
session.add(User(name="Gemini"))
await session.commit()
# Read
users = (await session.execute(select(User).where(User.name == "Gemini"))).scalars().all()Tortoise (链式 API):
如果你怀念 Django 的语法，Tortoise 就是为你准备的。模型类自带增删改查方法。
python
# Create
await User.create(name="Gemini")
# Read
users = await User.filter(name="Gemini").all()Piccolo (SQL 风格链式):
链式调用，语法接近原生 SQL。
python
# Create
await User(name="Gemini").save()
# Read
users = await User.select().where(User.name == "Gemini").run()Migration 能力
一个好的 ORM 离不开优秀的 Migration 能力，这几个 ORM 都有不错的数据库迁移功能，详细对比看以下表格。
| 特性 | SQLAlchemy (Alembic) | Tortoise (Aerich) | Piccolo (Built-in) |
|---|---|---|---|
| 成熟度 | 行业天花板。极其稳定，处理复杂场景。 | 较好，基于 Alembic 思想实现。 | 优秀，原生集成。 |
| 灵活性 | 支持手动修改迁移脚本，逻辑清晰。 | 相对固定，复杂修改有时会报错。 | 自动化程度高，甚至带图形化。 |
| 多库支持 | 完美支持多数据库、多 Schema。 | 较弱。 | 一般。 |
| 核心逻辑 | alembic revision --autogenerate |
aerich migrate |
piccolo migrations new |
PS：据说 Alembic 是你可以永远信赖的工具，虽然初次配置略显复杂，但它能处理任何怪异的数据库变更需求。
如何选项？
为了帮大家快速拍板，我整理了这份综合评估表：
| 维度 | SQLAlchemy 2.0 | Tortoise ORM | Piccolo |
|---|---|---|---|
| 行业地位 | 绝对统治级 | 异步界主流 | 后起之秀 |
| 迁移工具 | Alembic (工业级稳健) | Aerich (够用) | 原生内置 (体验极佳) |
| 管理后台 | SQLAdmin (需第三方) | 社区插件 | 自带 (颜值极高) |
| 类型检查 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 项目上限 | 处理复杂 SQL 的天花板 | 适合中小型业务 | 适合独立开发者 |
其他关键考量因素
类型提示 (Type Hinting)
- SQLAlchemy 2.0: 通过
Mapped类型，IDE 能实现真正的点选（Autocompletion），对开发大型项目极其友好。 - Piccolo: 原生类型安全，不需要额外的 Mypy 插件。
- Tortoise: 虽然支持，但在某些动态查询下类型推导会断掉。
性能与速度
- SQLAlchemy: 经过 20 年优化，在大量数据处理时性能非常强劲。
- Piccolo: 使用了极其轻量的底层实现，在简单的增删改查上通常比 SQLAlchemy 更快。
- Tortoise: 因为模仿 Django 做了很多层封装，性能相对是三者中最慢的（虽然在普通应用中感知不强）。
生态系统
- SQLAlchemy: 无敌。几乎所有第三方工具（Admin、加密、地理空间）都会优先支持它。
- Piccolo: 有自己的 Piccolo Admin，但其他生态插件较少。
避坑指南
- 关于 Stars 数的迷思： 千万不要迷信 Stars。Piccolo 虽好，但 1.9k Stars 意味着它的生态宽度不足。如果你在做一个涉及千万级资金、或者需要复杂数据库迁移的项目，请务必选择 SQLAlchemy。它的 11.7k Stars 换来的是你在深夜修 Bug 时能搜索到的成千上万条 StackOverflow 答案。
- 关于 Migration（迁移）的执念： 对于 web 项目来说，迁移工具的稳定性高于一切。Alembic 虽然配置稍微麻烦点，但它处理修改字段类型、多库同步等复杂场景的能力，是其他原生工具难以企及的。
- 关于 Admin 的诱惑： Piccolo Admin 真的很帅，像极了 TypeScript 生态里和 prisma、drizzle 类似的现代工具。但别忘了，SQLAlchemy 的丰富生态，也有类似的 admin 界面，而且 admin 界面只是本地开发时调试使用，真正交付还是需要开发真正的管理后台。
小结
对于我最近想做的一些新项目，我打算试试 LiteStar + SQLAlchemy 2.0 + Alembic 的搭配，到时会继续分享开发体验。
既然我们已经离开了 Django 的舒适区，就不要再找一个 Django ORM 平替。拥抱 SQLAlchemy 的 Data Mapper 模式，虽然前期辛苦，但它带来的代码解耦和对复杂业务的掌控力，显得一切都值得了。
另外我很看好 Piccolo，不过现在生态似乎不太成熟，再观望一下。