It does seem weird it’s not written anywhere replicas don’t exist… 🤔
It 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...)
IPSomething like this: https://github.com/Xiphe/cachified
I wonder if it’s possible to make a Cloudflare CacheAPI adapter for it…
I wonder if it’s possible to make a Cloudflare CacheAPI adapter for it…
GitHub
wrap virtually everything that can store by key to act as cache with ttl/max-age, stale-while-validate, parallel fetch protection and type-safety support - GitHub - Xiphe/cachified: wrap virtually ...
PI’ve read someone made a Cloudflare KV adapter for it, but Caching API is different right? (And cheaper?)
IIt's free! Not global, though. You can layer multiple levels (as in D1 > KV > Cache API), but not sure it's worth it at some point.
MReads from replicas are the same - we still have to keep a full copy of the database.
MNot free, but keep in mind $5/mo gets you 25 billion rows read: a lot.
Psweet, when can we expect read replicas to be enabled?
MThe Cloudflare Blog
D1 is now in open beta, and the theme is “scale”: with higher per-database storage limits and the ability to create more databases, we’re unlocking the ability for developers to build production-scale applications on D1
Uso what exactly is the spec for
I've got a column defined as
TIMESTAMPI've got a column defined as
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP2023-10-16 15:56:51
Ddate() time() YYYY-MM-DD HH-MM-SS
