北京
你问后端代码和数据库之间相隔多远？答案经常是“两个不同的世界”。你的函数部署在某云厂商的 us-east-1 区，Postgres 却跑在另一个区域，每次查询都要跨越这片距离。平时一条查询快到可以忽略，可一旦某个请求连续发出八条查询，每次都要经历一个完整的往返，原本毫秒级就能返回的端点，一下子拉长到接近一秒。
这种“异地恋”式的架构，几乎成了无服务器和微服务的默认配置。开发者习惯了连接字符串里填一对远程 IP，习惯了一点点延迟被业务体量掩盖。但 Neon 在 2026 年 6 月的平台预览中拿出了不同方案——Neon Functions，直接把计算放进数据库分支所在的同一个区域，还给出一个分支作用域下的专属 URL。这个做法反常识的地方在于：从来都是计算调度数据，而它让计算跟着数据库分支走。
我部署了一个简单的 REST API，专门用两种方式对同一条查询计时。一种是传统的跨区域请求，另一种是 Neon Functions 的同区计算。结果放在文末，数字的差距已经不是“略快”，而是不在一个量级。如果自己动手，可以用这个配套仓库部署一套感受一下。
整个后端只靠一个配置文件就撑起来了。Neon 的 CLI 提供了起步模板，REST API 就是其中之一。neon.ts 里三行声明就表达了全部意图：把 src/index.ts 作为一个名叫 todos 的函数跑起来，不需要填连接字符串，不用指定计算资源落在哪个区域，也不用预留什么 URL。部署时 DATABASE_URL 被自动注入，函数自动落在和数据库分支相同的区域。
应用代码里也没有任何 Neon 绑定。一个标准的 Hono 应用通过连接池和 Postgres 对话，跟你放在任何 Node 环境里的写法完全相同。解析环境变量、创建连接池、用 Drizzle 查询 todos 表，然后暴露 GET 和 POST 两个端点。一条 neonctl deploy 之后，这个处理程序就挂载在一个分支作用域的 URL 下，新建和读取 todo 的完整链路立刻打通。
“分支作用域 URL”这个词需要停下来仔细看。如果你从这个分支再拉出一个新分支，它会得到自己的函数和完全独立的 URL，运行的是你最新的代码。意味着每一个数据库分支都能拥有一份随行的计算能力，隔离且自动。当拉取请求触发预览分支时，后端逻辑和对应的数据副本天然就被拴在一起，不再需要人工对齐区域和连接串。
实测的数字就像文章底部写的那样——差距悬殊。跨区域的查询延迟在日常开发中可能被一笔带过，但放在连续依赖的场景下，累积的往返开销会把用户体验和系统吞吐拖垮。而让计算和数据库分支同居一个区域，本质是把“数据在哪里，计算就在哪里”这条老原则，从单机带进了云时代的数据库分支模型。这不是什么魔法，只是把之前被迁就的架构痼疾，用最直接的方式给解开了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
