> Importantly, when we enable global read replication, you won’t have to pay extra for it, nor will
Importantly, when we enable global read replication, you won’t have to pay extra for it, nor will replication multiply your storage consumption
MThe Cloudflare Blog
We've been heads down iterating on D1, and we've just shipped a major new version that's substantially faster, more reliable, and introduces Time Travel: the ability to restore a D1 database to any point in time.
IOne question I have about read replication, would it improve performance when writing to the DB? I now see a reduction in performance on write when running any sort of
SELECTAnd secondary question, any ETA on backups on the experimental backend? It's very hard to export data now, even a manual backup would be great in the meantime.
MClients will read from the (geographically) nearest read replica. That may sometimes be the leader (write+read). What kind of perf reduction are you seeing here?
M(Per the blog) We're entirely moving to Point in Time Recovery for the foreseeable future vs. snapshot based backups, since PITR is a) infinitely more flexible and b) is better than snapshots in terms of actually restoring your DB. What you won't be able to do until GA is export a DB directly.
INot much, tbh, but I've doing a lot of requests and I saw some slowdowns after a couple of queries in the console (somewhat big, but not massive ones). Understood. Will check next time the queue runs and in case report back 
One thing I'm not sure about iswhere would a scheduled Worker run and, more importantly (this was dumb 
) where the consumers for queues would run to locate the db closer to there (especially with the replicas on the horizon as the users would hit only the read side)
One thing I'm not sure about is
) where the consumers for queues would run to locate the db closer to there (especially with the replicas on the horizon as the users would hit only the read side)II see, so the wait is for the Time Travel feature... hopefully soon!
IA good export option would be nice regardless, tbh
MWe'd need to solve import - you may not care, but many others will. Import is also tricky to solve.
MYou shouldn't typically see a slowdown as our storage implementation is non-blocking (it's effectively a WAL-mode implementation):
WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
IOh yeah, I had to bypass that, too... but you can use a very big
.sql file if you really want to (up to a point)IIt might have been something else, unfortunately I don't have just DB calls, but also a
1.1.1.1 fetch and it's a queue consumer, so who knows. Will report back if it becomes a pattern 
MRETURNING *MINSERT INTO some_table (name) VALUES ('something') RETURNING id for exampleMsaves you a round trip to the db 
LHello, Quick Question about the Pricing. So for example I have a ordered List of IDs and select one small single Entry, it would maybe count as 4-5 Reads and now if I compare it to KV it would be 100x cheaper to retrieve a single Entry. And once there is Read Replication it'll be fast, too. My Question is how can it be so much cheaper? Like I understand the Pricing has to be like that for bigger Queries, but sounds to good to be true
LI know. Have you read the Question?
LNo the Database Solution would be 100x cheaper. Even tho it would count some reads on writing for the Index
UAs I have already said in the past the pricing difference entirely depends. If you max out the size allowed in KV, D1 would be an outrageous amount more.
d1-database
Though it is technically impossible to have that large of a record in D1. If all of your values are small D1 can definitely be cheaper given they bill based on units so the smaller the write/read the smaller the cost.
D1 storage does cost more though so at some point once you reach a certain storage amount KV will pretty much always be cheaper. Of course that depends on you reaching a fairly large storage amount.
Also note that reads on D1 each row that gets scanned even if not returned will add to the bill so if you have a bad query that scans the entire table you could in theory be billed quite a lot of read units per query.
d1-database
Though it is technically impossible to have that large of a record in D1. If all of your values are small D1 can definitely be cheaper given they bill based on units so the smaller the write/read the smaller the cost.
D1 storage does cost more though so at some point once you reach a certain storage amount KV will pretty much always be cheaper. Of course that depends on you reaching a fairly large storage amount.
Also note that reads on D1 each row that gets scanned even if not returned will add to the bill so if you have a bad query that scans the entire table you could in theory be billed quite a lot of read units per query.
YRunning into an error today when trying to apply migrations. Was working fine for me yesterday so not sure whats going on.
YYeah agreed
Mwhen you apply a migration for an experimental backend db, (for now) you need to pass
--experimental-backendahhh ok thank you
LI'm not entirely sure but logically it has to scan every CompanyName or atleast the first digit, because even the last row could be this CompanyName. Could be fixed by setting a Limit at the End for example to find only the first one. But yes an Index sorted by CompanyName should help alot. Basically would change from O(n) to O(log(n))
LAnd keep in Mind the Reads are Size based. If your CompanyNames has an average length of 8 chars it would take 500 scans for one Read Unit. But maybe the Where statement is optimized so that it doesnt even read the entire CompanyName
LNevermind I think im wrong with the Index. The WHERE LIKE statement can be different and also search if something contains anything. I don't even think a Index would help there and it's always O(n)
LNot if you have a % at the start and at the end, thats always an entire Table Scan
LBut you could try to use Contains instead of Like that should be faster and is more optimized I guess
