I thought I’d try out using PlanetScale rather than Fly.io’s Postgres offering, however it seems I’m getting much slower response times. Nearly 400ms for a very basic query vs 2ms on Postgres. My fly.io app is on “lhr” and PlanetScale on “eu-west-2” which I believe is one and the same? I’m also getting faster times running the app locally on my machine here in Belgrade connecting to the same PlanetScale instance which doesn’t seem right.
2 Likes
I think it isn’t comparable because Fly Postgres VM runs on the same network as the app’s VM. So latency is very very low.
Sure, I would expect it to be higher. But seems very high such as to be unusable.
Check ping times to the planetscale instance.
1 Like
I can ping from my machine of course, but if I ssh into my fly.io vm ping is not installed, and I’m not sure how I can install it?
UPDATE: Installed it but the server doesn’t respond to pings it seems.
UPDATE2: Did manage to do a traceroute. Looks like maybe there is a strange detour via the US?
traceroute to aws.connect.psdb.cloud (3.223.179.78), 30 hops max, 60 byte packets
1 172.19.128.97 (172.19.128.97) 0.209 ms 0.163 ms 0.144 ms
2 205.234.240.65 (205.234.240.65) 0.735 ms 0.721 ms 0.708 ms
3 ae25-101.cr1-lon1.ip4.gtt.net (69.22.139.9) 0.356 ms 0.236 ms 0.214 ms
4 ae15.cr3-nyc6.ip4.gtt.net (89.149.186.217) 69.412 ms 69.405 ms 69.397 ms
5 ip4.gtt.net (209.120.155.138) 70.684 ms 70.677 ms 70.670 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 52.93.28.246 (52.93.28.246) 74.820 ms 52.93.28.230 (52.93.28.230) 74.864 ms 52.93.28.240 (52.93.28.240) 85.470 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 ec2-3-223-179-78.compute-1.amazonaws.com (3.223.179.78) 75.629 ms 74.697 ms *
Yes, something weird must be happening for the latency to be this bad. Taking a detour thru the US is definitely sufficiently weird.
I believe that PlanetScale hostname uses geo DNS to route to the nearest instance. Here, it looks like AWS returning a US IP for DNS lookups. AWS shouldn’t be doing that, though.
That shows different IPs in European cities, which is what I’d expect.
We probably can’t do anything about this because it’s AWS Route 53 making a poor choice. PlanetScale might have regional hostnames you can use, and you can grab one of the appropriate AWS IPs to test with to see if it helps with latency.
2 Likes
If you need a third-party alternative, with low latency, I’ve been using DigitalOcean’s PostgreSQL and MySQL offerings, with apps hosted on Fly, and it works rather well.
You have to make sure app/database regions are the same to have low latency. In my, not very scientific, tests, latency didn’t really increase compared to Fly, perhaps they are even on the same datacenter.
1 Like
PlanetScale are looking into it, so we’ll see what they come up with, but yes looks like the data is potentially going the long way round.
If no luck, then of course there are other providers to try…
Hi @neofight78,
(I work for PlanetScale) 
Could you try updating your connection string to use aws-eu-west-2.connect.psdb.cloud? That’s the regional URL for eu-west-2.
I believe that should solve it, please let me know though!
4 Likes
Interestingly traceroute shows a much lower latency for that hostname, but using it in the connection string didn’t make an observable difference to the performance.
Could you share more details about your app? Stack? How you are connecting?
Could you check the PlanetScale Insights page as well, are you seeing slow query times there? (just to rule that out)
Sorry, I was being a dummy and updated it in appsettings.json but not the secret stored in fly.io. I’ve updated the connecting string there too and now I’m seeing about 10ms to execute each query. A significant improvement!
3 Likes
great!
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.