FastAPI作者用95张表手写SQL

「95张表，9个业务域，零ORM。」

这是Rohan Kumar在技术选型复盘里扔出的数字。三个月前他启动一个AI Agent项目时，没人推荐他这么干。三个月后他承认：有些坑，踩过才知道有多深。

从Fastify到FastAPI：一场"熟悉的陌生感"实验

Rohan的底色是JavaScript。React写了多年，后端用过Express和Fastify。当他决定切Python做AI项目时，第一个问题不是"用什么"，而是"别让我太难受"。

FastAPI的语法让他愣了一下——装饰器路由、async/await、类型提示居然真的生效。这不像学新框架，倒像把Fastify的代码用Python重写了一遍。技术决策里，"熟悉感"往往被低估。Rohan没否认这点：「I'd be lying if I said it wasn't a factor」，但技术理由同样站得住脚。

他的系统要同时处理三件事：n8n的并发webhook回调、React仪表盘的实时轮询、PostgreSQL的持久化asyncpg连接。全是异步I/O，而FastAPI从出生就围着这个模式转。Django后来补了异步支持，但用起来像 retrofit（后装补丁），不是原生设计。

代价在三个月后才显形。

没有Django的免费管理后台，他花数周从头写React仪表盘。没有内置迁移系统，他用原始SQL文件通过SSH管道进Docker，再喂给psql。复杂语句的shell引号在SSH→Docker→psql三层传递中被反复转义，「mangles complex statements」——他原话。

插件生态更薄。Django 20年前就有的功能，他得自己造轮子。

95张表与手写SQL：一场控制狂的豪赌

Rohan主动跳过了ORM。95张表分布在9个业务域，他想看清每一条SQL长什么样。没有魔法，没有N+1查询的惊喜，没有迁移框架生成他读不懂的语句。

这个决定的底气来自数据结构的本质。交易关联银行账户，邮件分类引用消息实体，知识事实从多源交叉验证，调度任务指向Agent再指向模型——关系嵌套关系，事务套着事务。MongoDB的方案是反规范化，文档里嵌文档，一致性自己手工维护。PostgreSQL的ACID在这里不是卖点，是刚需。

但PostgreSQL还藏了一手牌。

LISTEN/NOTIFY机制替他干掉了消息队列。邮件分类完成的瞬间，触发器发射通知，brain服务通过asyncpg毫秒级捕获并响应。没有Kafka，没有RabbitMQ，用的是Postgres 15年前就内置的功能。

CREATE OR REPLACE FUNCTION notify_email_classified()...

这行代码省掉的不仅是基础设施，是运维心智负担。

选型没有标准答案，只有被低估的上下文

Rohan的坦诚在技术博客里少见。他区分了两种决策：informed decisions（知情选择）和"I already know this tool, and I need to move fast"（熟悉工具优先）。两者都合理，但代价曲线不同。

他给后来者的建议很具体：如果你的项目是传统web应用——用户账户、管理后台、表单提交——直接用Django。FastAPI的舒适区是API层，协调多个服务之间的数据流，这正是他的处境。

这个判断和三个月前的选择形成微妙张力。他没说后悔，但「bitten me more than once」的表述已经够重。

技术选型的残酷在于：你只能在事后知道哪些"合理"其实是"侥幸"。

Rohan的幸运在于，他的数据模型确实关系密集，PostgreSQL的LISTEN/NOTIFY恰好覆盖了他的实时需求。如果业务突然需要复杂全文检索或地理空间查询，那95张表的手写SQL维护成本会呈指数级上升。

他没提测试覆盖率，没提团队规模，没提当协作者打开代码库时的 onboarding 成本。这些沉默本身也是信息。

文章结尾，Rohan留了一个未完成的思考：「Both are valid, but they lead to different trade-offs down the line」——两种选择都成立，但代价会在未来某个节点兑现。

你上一次技术选型时，"熟悉感"占了多少权重？三个月后，这个比例让你安心还是心虚？