如何选择后Django时代SQLAlchemy 2.0、Tortoise与Piccolo三大异步ORM?

摘要:前言 从 Django 的避风港走向异步星辰大海 ——题记 最近的空闲时间,我折腾了 TechDistill 项目,可以看到近期的公众号推送都是「AI科技日报」,这就是 TechDistill 项目的产物,在每天快速迭代的各类技术新闻中,开
前言 从 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 极其友好: 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 模型写法。 class User(Model): id = fields.IntField(pk=True) name = fields.CharField(max_length=30) Piccolo 简洁到了极致,为异步和类型安全而生,语法非常现代。 模型定义直接继承 Table class User(Table): name = Varchar(length=30) CRUD 操作对比 SQLAlchemy (显式 Session 模式): # 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 就是为你准备的。模型类自带增删改查方法。 # Create await User.create(name="Gemini") # Read users = await User.filter(name="Gemini").all() Piccolo (SQL 风格链式): 链式调用,语法接近原生 SQL。 # 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,不过现在生态似乎不太成熟,再观望一下。