Slow free tier; Are there any significant differences between free and pro plan response times?
Upon cursory evaluation of the Supabase free Postgres instance, I'm getting response times of > 1s for simple queries and inserts for initial queries,
but improves for close subsequent requests only to revert back again to > 1s after a few seconds.
This is running on my local machine connected to the Supabase database.
I really want to use this service but would like to evaluate the latency on Pro.
Are there any differences in things like "vCPU" and "IOPS" for free and tier that would account for this difference?
12 Replies
You mention Prisma is your request coming from Prisma as an SQL dataport request directly
If thru the rest api a browser will require two round trips for options and then the actual request.
You should do explain/analyze to see if is is the Postgres server or connection. If rest API there is a modifier to do that. In SQL just google that.
There is no difference between Pro and Free for the basic Pro instance.
This is a SQL dataport request
1 second is a very long time for a small table operation.
Yes I agree. I'm not sure why this is happening
I assume no RLS is involved then either.
Yes. That's correct
I would run explain/analyze to rule out it is the actual query.
As you have not mentioned number of rows or the query it is hard to speculate if it should be fast. Single row queries in an 100k table with an index are usualy single digit msec for the database part.
Oh it's just a single row, but I will check
I determined this is coming from Prisma on the initial database query. It can take anywhere from ~1-3s on first query, but this improves on subsequent queries. Why is this
I don't know anything about prisma. Normally the database will load tables from disk to memory. If those tables are still in memory then they would be faster on following requests is one guess. Same with indexes.
how far is your client from the supabase instance? it could be TCP slow start in just making the connection. i'm assuming Prisma reuses the connection to the DB for subsequent queries.
I am in the Philippines and the instance is in ap-northeast-1.
I am testing locally from a local docker container.
The latency doesn't make sense to me.
It's cut in half upon using the connection from the pool.
From say 3s to 1.5s
how long does it take to make the connection from the
psql command line client? or any other local desktop client like DBeaver? There are so many moving parts here you need to isolate which one is being slow.