You will never get faster than on-prem perf with a remote DB
You will never get faster than on-prem perf with a remote DB
SIf DB perf is a requirement, you might want to look into on-prem. As far as I'm aware, D1 offers easy scalability (due to CF having 200 trillion servers, real number btw)
Rhi ummm, I couldn't find current D1 limitation article? could anyone mind to share it
Roh, there is pinned message
RI see then, let me stay with MongoDB Atlas
IIs there a way to see per table sizes (and even index, possibly) in D1?
II know
dbstat can exists, but doesn't look like it's there.
HI would note that D1 can(once replication goes live) theoretically be faster than on-prem if you still use Workers. As in, you would have to have/managed many DBs to be able to match the scale/locations of D1
SAh yes, I was speaking from the perspective of him using php remote to D1
SWe fully transitioned from mongodb to d1 yesterday and it's plenty fast! The python script that runs on our server updates the DB while our pages functions act as the client which return the results on our api. Considering that many requests happen every minute which receive the same output how could we cache the response for example one minute in order to not burn row reads?
CUse the cache API to cache responses. The function will still run but will reduce usage of D1
JHey all, I'm new here. I'm noticing really slow performance using D1 (cold and hot runs) in other countries like Germany and Australia. I'm getting ~1200ms on cold starts and ~700ms on hot. Is this normal for the beta?
IWhere is the D1 located? Or better yet, where have you created it from?
ITrue, I assumed the current beta database version, but yeah…
JTo clarify, my queries were just for reads.
Most recent version, I think? Just created the D1 on Oct 1st and testing with a deployment made yesterday. I think it was in us-east.. but not sure where to check the region.
Most recent version, I think? Just created the D1 on Oct 1st and testing with a deployment made yesterday. I think it was in us-east.. but not sure where to check the region.
IIt is the closest location, in which D1 is supported, from the location you hit when you create it. So if you are in us-east, it would have been created in and around there.
ISo a 700ms latency, with the ocean crossing might make sense, even though it seems a bit high. How did you fetch it? Via a Worker?
IYou should see actual database execution times in the query response json (under meta)
JIt's via a worker. I'll have to check the meta. Should I expect their to be any regional or edge caching with D1 in the beta? In latency testing in US-Mich, Germany, NL, and Australia, I haven't seen faster latency than a singe region RDS micro instance.
IThere will be read-replicas, but an ETA is currently unknown. You can do your own caching in the worker via the cache api
JAh, got it that makes sense for now. I'd make a note in the d1 docs to mention this as a workaround, as it wasn't clear to me if I was going to roll out an app.
IYeah, but it works and it won’t be needed in the long run (even though it’s reduce costs, so it makes sense all the time, tbh)
DHey Matt, I'll bump this message with another "use case", or more correctly, reason to implement - ORMs and libraries. Lots rely on transactions being a thing, and db.batch doesn't fully replace, as you can't split them and execute business logic inbetween queries.
Do you have sql transactions on the roadmap somewhere?
Do you have sql transactions on the roadmap somewhere?
Panyone ran into issues where migrations list works when using --local but not when trying to apply to prod? i just get empty output when running against prod (no errors). trying to migrate a new database for first time
POh, D1 isn’t actually on the edge just yet then? I had assumed the workers would be querying from the closest D1 instances, making for very fast reads. Isn’t that the main value prop of d1?
PI’m not seeing anywhere on the website where it states that the read replicas are disabled. I was looking to launch Monday so this is terrible news for me. Anyone have info on this?
OWould be great to see some work done on wrangler validation generally around naming conventions. One of my team created a table in the dashboard with a hyphen in it.
ID1 is on the edge, it’s generated closest to where it’s generated. Read-replicas aren’t here yet,during the beta.
IIt will still work, it’s just not distributed. It’s a beta after all…
IIt does seem weird it’s not written anywhere replicas don’t exist… 
JI think people expect D1 to behave more than Turso where DB read and writes are made only to a local db edge instance, which is asynchronously later sent to the primary region. This keeps writes and reads fast for the worker as it doesn't have to wait on the primary region (outside of cold starts sync).
https://docs.turso.tech/concepts
https://docs.turso.tech/concepts
Concepts for understanding how Turso works.
POk, so you’re saying the main database, which is the single source of truth, exists in the location closest to where it was created?
PYes this is what I expected! Will this be how D1 works once read replicas are live?
PI get that it’s beta, but I wasn’t expecting the main value prop to be missing at the moment. I mean… I could have kept my Postgres database and just added caching, there’s no difference right?
PYea, total gotcha. I’m bummed
IAs far as I know that's never been what the premise was. Single source of truth, edge, close to the first creation location + read-replicas spread around the world (not sure how this works, as I'm not on the team as you know).
IYes, and it always was planned and explained that way. Write will always go there.
IYou can still add caching, that is still true... and will always be reccomended, you pay per row read and written, so the less activity, the less it costs. And the Cache API on Workers is free.
IAs far as read-replicas, I'm 100% sure it was said here multiple times, by many. I always just assumed it's in the docs somewhere, but I might have been wrong there.
IIt's also a beta, which is clearly marked for non-production workloads. There are issues that happen sometimes.
IGonna add that in no place, where D1 open betas where announced, did anybody say that read-replicas were a thing:
What’s next for D1?
We’re setting a clear goal: we want to make D1 “generally available” (GA) for production use-cases by early next year (Q1 2024). Although you can already use D1 without a waitlist or approval process, we understand that the GA label is an important one for many when it comes to a database (and as do we).
Between now and GA, we’re working on some really key parts of the D1 vision, with a continued focus on reliability and performance.
One of the biggest remaining pieces of that vision is global read replication, which we wrote about earlier this year. Importantly, replication will be free, won’t multiply your storage consumption, and will still enable session consistency (read-your-writes). Part of D1’s mission is about getting data closer to where users are, and we’re excited to land it.
— https://blog.cloudflare.com/d1-open-beta-is-here/
PThe Cloudflare Blog
Today, we’re excited to announce D1, Cloudflare’s first SQL database, designed for Cloudflare Workers
PI think this might be the one that got me
IYeah, in the announcements they talk about read-replicas, but in both the open alpha, and open beta it's mentioned replication isn't here yet.
PThat cross referenced with the “Limits” page
IThe open beta blog post mentions a GA timeframe of Q1 2024, in which that is expected to exist.
PSo really the only way to find out is dig through discord, or just so happen to see it like I did
Plol
IWell, no. Also in all open alpha and open beta blog posts it's mentioned it's not yet included...
POh really… I didn’t notice it was mentioned as not included
IYeah, it's in there.
