Just sharing some feedback about read replicas here publicly:
Read Replicas are super cool and long awaited, when they work well they do a good job of making queries low latency world wide, and sessions api isn't too hard to use in my opinion.
But I think they're a bit hard to recommend for most use cases right now, for a few reasons:
In the shorter term, there's a good amount of errors with them. I've gotten nearly 10k errors in the last 2 days or so, like 10% error rate or so on queries, from simple select queries. Mostly network connection lost and internal errors. D1 team has said they're aware, but it's still painful to use with, need lots of retries. Don't think database specific, seen this across 3 super simple DBs.
I'm sure that'll be fixed with time, but the bigger issue I see is with cold starts. D1 has always had cold starts with 30-40 seconds of inactivity, pretty quick, that results in incurring a cold start on the next query. However, they seem worse with read replicas.
It seems to be location dependent, for a db with primary in enam (~16 KBs or so size)
enam replica cold start - 1s
eeur replica cold start - 2-3s
apac replica cold start - 4-5s
normal non-replication cold start for same db: ~300-400ms
Perhaps because it's re-syncing first before answering traffic? I would think it could revive the replica quickly and sync async, but perhaps it doesn't work that way? It'd be really nice if either the keep alive without any request was longer (like 10m-15m) and/or the cold start was reduced.
Unless you have high RPS world-wide, I think currently you'd be better off with read replicas off and keeping your primary warm (or incurring its much smaller cold starts). Even if you have active traffic in EEUR with an ENAM Primary, infrequent requests from APAC will still be painful for users. Maybe more precise replica configs could help that too.
It's beta though, and I'm sure with some more love it'll be super useful to have on for workers apps soon.
K
A
M
C
C
Z
M
J
C
_
