db session lookup adds 41ms to every request on neon, is that normal Sessions

41ms is not the cost of a session lookup, it is the cost of your connection. A primary key read against 4,000 rows is sub-millisecond in the database. What you are measuring is almost entirely connect plus TLS plus network round trip.

In order:

• Use the pooled connection string, not the direct one. Opening a fresh connection per invocation is most of your 41ms.
• Check the region of your functions against the region of your database. Functions in one continent and Postgres in another is a flat 80-100ms tax that no query tuning will touch.
• Then cache the session in whatever edge KV you have, keyed by the cookie, 60 second TTL. Most requests then never reach Postgres at all.

After that a session lookup costs about 1ms and the debate about sessions versus tokens stops being about performance, which is where it should have been all along.

Instrument before you change anything. Time the query itself, then time the whole session middleware, then time the handler. If the query is 0.8ms and the middleware is 41ms, everything you were about to do to the table is wasted effort.

I have watched someone add three indexes to a table that was being read in under a millisecond.

Also ask how many of those requests needed to know who the user was. Static assets, public pages, cached routes, health checks. If your middleware runs on everything, you are paying 41ms on requests that would have been happy anonymous.

Switch to JWT. This is exactly the problem stateless sessions were invented for - no lookup, no round trip, 0ms.

Check whether your ORM is doing two queries. A lot of session adapters fetch the session and then fetch the user as a separate statement, so your "one lookup" is two round trips and the fix is a join or an include.