We'd need to solve import - _you_ may not care, but many others will. Import is also tricky to solve
We'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-backend
Yahhh 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
LAnd if the Company Name contains multiple Words you can look into a Fulltext Index, but I mean this type of Queries will always scan alot of rows
MYou could fully scan a 1GB table 100,000 times before you reach the included 25 billion reads. Read units might add up fast but we give you billions and charge 1/10th of a penny per million.
UThat is true, I dont know what the cost for each would be for a normal usage as an actual database was mostly pointing out that KV is meant for larger storage blobs where if possible to store on D1 wouldnt be suitable cost wise 
UProbably shouldve made that more clear to be fair
MD1 should always be cheaper for SQL/queryable type workloads. If you’re treating it like a big KV store with > 1MB rows then yeah, it’s not a good fit. That’s OK - that’s what KV is built for.
MEntirely agree.
