Queries slow even with accelerate
I don't know what to expect, but queries seems very slow. Using Prisma postgres with accelerate, all my queries incl. simple ones like findUnique with where clause on primary key and very few columns, takes at least 250ms (seen via Prisma Optimize).
Located in Denmark (running Nextjs locally).
Probably network latency, but is there anything I can do about that ? I was under the impression accelerate made data "global" with fast local access.
9 Replies
You decided to hold for human wisdom. We'll chime in soon! Meanwhile,
#ask-ai is there if you need a quick second opinion.Hey đź‘‹
Can you try appending withAccelerateInfo to your query and check if the response is being served from cache or not?
Accelerate: API Reference | Prisma Documentation
API reference documentation for Accelerate.
Hey!
I have added withAccelerateInfo to one of the findUnique queries, and I guess it is hitting the cache, but the responsetime (it says Latency, but I guess it is the total responsetime) is still at least 60ms for this very simple query , and very often higher (and that table only has 1 row). Also it does not seem that the cached responses are faster than the first one (cachestatus=miss). I have attached some debugging info.
Thx. for looking into it.
The measurements are from my local env. so my network could be a bit slow.
But if I measure from Vercel (hobby plan) I also get very slow responses. Another findUnique query (very very few rows) gives these long times:
Thanks for sharing the stats! Your Prisma Postgres region is the Europe one, right?
Hey - no db is "US east (N. Virginia), and so is my Vercel functions. So diregard stats from my local machine and only look at queries from Vercel - they should be fast because app functions and db are colocated. Stats from Vercel attached. The usersubscription.findUnique query has a where clause on userId which has a unique index on it:
model UserSubscription {
id String @id @default(cuid())
userId String @unique
stripeCustomerId String @unique
stripeSubscriptionId String @unique
stripePriceId String
stripeCurrentPeriodEnd DateTime
stripeCancelAtPeriodEnd Boolean @default(false)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
Strange that it is so slow ... ?
Another thing - is it possible to get a connectionstring for the db and connect to it via pgAdmin?
Ah okay, it indeed is a bit strange if your functions and database is in the same region 🤔
is it possible to get a connectionstring for the db and connect to it via pgAdmin?Not at the moment, but it will be possible very soon. Support for direct TCP connect (required for connecting to pgAdmin) is on our radar. This will be possible once Prisma Postgres is out of Early Access and is production ready
Ok, any input how to find the cause of the slow queries ?
Ping...
I am wondering if this could be due to cold start. Can you make quick repeated requests in short succession to see if performance changes drastically on “warm” vs. “cold” runs?
Also, can you try enabling logging to get the underlying SQL query? We can then pass the SQL query to EXPLAIN ANALYZE and check the query execution plan