There will be read-replicas, but an ETA is currently unknown. You can do your own caching in the wor
There 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.
IIn the Open Alpha announcement: "The biggest pieces that have been disabled for this alpha release are replication and JavaScript transaction support."
In the Open Beta announcement: "One of the biggest remaining pieces of that vision is global read replication, which we wrote about earlier this year."
In the Open Beta announcement: "One of the biggest remaining pieces of that vision is global read replication, which we wrote about earlier this year."
PYep, I see that now. Thanks
PLuckily I abstracted away the database behind a repo layer… so I can swap it out
PDo you know if reads from a read replica will be charged as well? Or is that kind of “caching out of the box”?
PThat would be awesome
IAs far as I expect, as I haven't had more details than you do, they will be charged normally.
IYou won't be charged more for the read replicas themselves. So no storage nor replications costs.
PSo that’s what they mean… well here’s to hoping reads from it are free as well 
That would be insane for adoption
That would be insane for adoptionII really doubt that... but hey, the Cache API still exists 
PAny really good typescript libs for the cache api?
IThere is the usual
workers-typesI’ll have to find one that is vendor agnostic
PWith an adapter for CF
IThen I've got no clue, unfortunately.
PNo lock-in here!
IDo note that the Cloudflare Cache API implements a subset of the normal Cache API from Service Workers.
https://developer.mozilla.org/en-US/docs/Web/API/Cache
https://developer.mozilla.org/en-US/docs/Web/API/Cache
I(Ok, technically the CacheStorage part, you need to open the cache...)
