ANevermind... I just read "D1 will create read-only clones of your data and distribute across Cloudflare global network — close to where your users are — and constantly keep them up-to-date with changes."
ZThere hasn't been a focus on performance for D1 yet, as it is still in alpha. Benchmarks made right now likely wont reflect the speeds when it goes GA
ZYup
Myeah we were more focused on just getting it out into people's hands than performance for the alpha
Jd1 has a limit in storage right now
Ji imagine its going to be price competitve but time will tell. If you are just starting a project i wouldn't really worry about which Database you chose as you can just manually copy over the tables and stuff when you are ready to release to the public with the database you want
Aseems like they are always cheaper than the competition. Like Bit.io is $1 per 100M operations... so cloudflare might be like like 25% of that if I compare KV and other products how they are priced?
Mnothing official from what I've seen, but my guess based on the models of KV and D1, is that D1 writes will be much cheaper than KV writes. I think of KV as behaving like a config file - frequent, simple reads, occasional writes, whereas D1 is a database, meant for complex queries, frequently, all the time
Mmy guess is that the pricing model will be similar to R2, with operations being split up into classes (class A might be CREATE, DROP, ALTER etc, class B might be INSERT, DELETE, UPDATE, class C might be SELECT) depending on complexity and cost, which would depend on the internals of sqlite
Mdepends on the scale of your project
MI'm creating an experimental branch of my website on D1 to see how well it works, and when D1 goes GA and official pricing info comes out, I'll probably switch over to D1 entirely, but on the off-chance that D1 is prohibitively expensive, I'll just cut the experimental branch and keep us on our current solution
Meither way, remember D1 is still in alpha and shouldn't be used in production yet
Myeah
MI've encountered some odd/buggy behavior and HTTP 500 errors coming back from the API
Myep
Mjust tell us here
MI'm ridiculously online
Mif it's returning a 7501 error most of the time you can safely retry
MI was just using the dashboard interface to set up my tables, trying to INSERT INTO more than 2-3 values at a time causes a 500, and now whenever I load the list of tables I get 500 as well
Mthe weirdest behavior was the console showing internal error but the operation succeeded
Mthe console tab? can you DM me what you were trying to run, I'll try fix it tomorrow
Mofc now I can't get it to reproduce the error I was getting in the console tab ...or the 500 error when trying to load the tables tab
Mguess it's working then lol
Myeah might be that bug where it's safe to retry
Mah... figured it out - was my own mistake because I primarily use MySQL. I tried to do the following, which works in MySQL but doesn't work with SQLite
MFor whatever reason that produced a 500 error when I first tried it, but now it correctly returns the SQLite error
MI still get sporadic 500 errors when I try to load the tables tab, can't figure out why. I'll go ahead and send over the database info in case that's of any help
HGenerally yes, but many apps just don’t work very well on a KV model
EI'm personally expecting it somewhere in between R2 and KV pricing wise, as D1 isn't distributed globally like KV is, and the processing cost will be covered by the worker executing the query, but I've no idea all the stuff they're doing behind the scenes for transnational requests etc which might drive it up.
EI hope it's close to R2 pricing wise, with replicated read replicas costs based on usage, and the compute costs being one of the higher parts but that's basically the worker executing the query.
Although I don't think it'll be like that, they'll likely need something funky behind the scenes to support D1 instances >100MB as that's more than a worker can store in memory, so perhaps it'll be simple pricing for small D1 instances and complex pricing for larger D1 instances? Who knows
Although I don't think it'll be like that, they'll likely need something funky behind the scenes to support D1 instances >100MB as that's more than a worker can store in memory, so perhaps it'll be simple pricing for small D1 instances and complex pricing for larger D1 instances? Who knows
Wwhat do you mean?