Why per-database-connection request

[mivinci]

It seems that apps/api creates a new database connection for each request, according to https://github.com/unkeyed/unkey/blob/main/apps/api/src/pkg/middleware/init.ts.

I know that a global connection instance is not allowed outside the entry of Cloudflare workers, but have no idea why we can live with that.

More than just Unkey, I've seen a lot of code snippets showing such an approach on other serverless JS runtimes.

Can somebody please explain?

[chronark]

We connect to the database via http, there is no long living connection like in traditional tcp based database connections.

[mivinci]

Okay it looks like using an HTTP client for each request has gone mainstream in the serverless world since allocating memory for an HTTP client is relatively acceptable. Thanks for your help )

[kinthaiofficial]

Per-connection request verification is the right architecture for agent-facing APIs, even if it seems heavy at first glance.

The reason it matters in a multi-agent context: when Agent A spawns Agent B which calls your API, you want to know that the specific call came from Agent B with Agent A's authorization, not just that "some entity with the right key called." Per-connection verification with a trace token makes this attribution possible.

A few things that make per-connection auth work for agent workloads:

Session-scoped HMAC tokens — instead of verifying asymmetric signatures per-request (expensive), issue a short-lived HMAC token at session start (one asymmetric verification) and use it for all calls within that session. ~10x faster than per-request asymmetric auth, with the same security properties.

Delegation chain in the token — the session token should carry the delegation chain (root agent → calling agent → immediate caller) so your API can enforce "this agent is allowed to call X on behalf of Y." Without this, you can only enforce "this key has permission" but not "this agent in this context has permission."

Cost attribution metadata — each request should carry the agent's remaining budget so your API can apply rate limiting that's budget-aware, not just request-count-aware. An agent that's nearly out of budget should be throttled differently than one with a full budget.

Audit receipt — on sensitive operations, return a signed receipt that the calling agent can include in its own audit trail. This closes the chain from "user instructed agent A" to "agent A instructed agent B" to "agent B called this API."

More on the agent identity/auth design: https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons

Is the per-connection architecture primarily for security, cost attribution, or both?