TL;DR
I deployed a Hono API on Prisma Postgres and Prisma Compute with three commands, auth login, build and deploy, and I never installed Bun.
O...
For further actions, you may consider blocking this person and/or reporting abuse
The three-command setup is appealing, but the production edge is usually connection behavior under cold starts and bursts. Did you measure pool creation, retry behavior, and time-to-first-query separately? That would help readers decide whether the convenient path stays convenient under load.
Fair point, Alex. I didn't measure pool creation, retry behavior, or time-to-first-query separately. I have end-to-end request times from India. The first requests after roughly 16 hours idle took 682.7 ms on
/healthand 363.5 ms on/bookmarks, but those timings mix in DNS, TLS and any wake-up, so I can't isolate pool creation or time-to-first-query. The 30 warm requests per endpoint had medians of 120.8 and 127.5 ms.I did test five simultaneous identical POSTs, which produced one
201and four409responses, as expected. That verified duplicate handling, not connection behavior under load. I haven't tested retry behavior, the pooled connection string, or what happens when idle database connections drop. The three-command path worked for getting the app live, and the 85-check smoke test passed, but connection behavior under load remains an open question. If you've measured this on Compute or elsewhere, I'd be interested to hear what you found.Those warm medians are useful, and the honest boundary around them makes the post stronger. I would add a tiny follow-up matrix for cold start, first query after connection loss, and a retryable failure. Even a few measurements there would turn the open question into an operational contract.
A small matrix like that would turn the open question into a clearer picture of the connection behavior. I haven't run those scenarios as a controlled matrix, apart from the idle timings above, so the post stays within the limits I described. Cold start, first query after connection loss, and a retryable failure are the right three cases to measure next. If I run them, I'll share the results here.
If you add routes to this scaffold and
/usersstarts returning a 500, check the server log first. The response pointed me toward emitting the contract and applying the schema. The schema was fine. The actual cause,DRIVER.ALREADY_CONNECTED, only showed up in the log.Have you run into an error message that sent you down the wrong path? I'd be interested to hear what the error said and what eventually helped you track down the real cause.
That order-dependent /users 500 is brutal, it passing when /users ran first and failing after bookmarks is the kind of thing a quick manual check would miss.
Thanks, Odinaka. What made it trickier was that my second smoke run passed with no code change. I'd restarted the server, and the script requests
/usersbefore any bookmarks route, so the explicitconnect()ran first. In my tests, the 500 appeared when a bookmarks request ran first on a fresh process.One useful check when adding routes to a scaffold is to hit the template's own routes both before and after the new ones. The Prisma runtime reference explains why the order matters: call
connect()before any query, or not at all.That passing second run is the nasty part. Hitting the template routes before and after the new ones is a clean way to make the order show up instead of hiding it.
The route querying before the template initialises is such a familiar serverless trap. Good catch, and the three-command deploy is genuinely nice.
Thanks, Rowan! The route-order issue was particularly tricky to catch. Glad you liked the three-command deploy too! 😊
Wow, you really went through a lot of testing for this one, Shubhra! Loved that you shared the things that broke too. That's actually super helpful 😀
Thank you so much, Hema! 😊 I wanted to share the things that didn't work along with what did, because those were some of the most useful parts of the whole process. I'm really glad you found them helpful!