These timers are started after Lambda initialization and do not include "cold start".
It's possiblt this ↑ iframe will exceed its 5s timeout. Try a refresh.
1 An initial query — SELECT now() — is made in case the Neon instance is suspended.
That connection is closed and a new one is create for the subsequent query when the db is active.
2 Architect's #tables() method is used to discover the DynamoDB table name.
This lookup is cached between requests and will be 0ms when the Lambda is "warm".
Which db should I use? Like most things in web engineering, it depends.
(Setting aside the fundamental difference of tables+rows and documents; even if that's probably the most important factor.)
Neon works surprisingly well in a "cloud function" like a Lambda! But at ~4s, its boot time can easily timeout a 5s Lambda. On the other hand, if it is already active, the ~150ms query with the @neondatabase/serverless package (uses WebSocket instead of TCP) is very fast.
Still, using Arc + DynamoDB is the most consistent in terms of speed. At its best, a query can be just a few ms! And at its worst, that initial query will be < 300ms. It makes sense that AWS's baked in datastore would be very reliable when you need to access data quickly.
This test runs on a vanilla Node.js v16 Lambda with the ARM64 architecture. The Neon team is focused on CloudFlare Workers and Vercel Edge runtimes — which differ from this environment quite a bit.
Also, this test doesn't...