BTW R2 is open beta now: https://blog.cloudflare.com/r2-open-beta/
R2 is 3x more expensive than B2 (storage) https://www.backblaze.com/b2/cloud-storage-pricing.html Am I missing something? Is there no bandwidth cost at all?
D1: Our SQL database
141–150 of 241 posts
Re: D1: Our SQL database
#142* How do you replicate it consistently?
* Who has the master privilege (or masters if sharded)? What's the failover story?
I am guessing a blob store is involved, but I have gaps in my understanding here.
Re: D1: Our SQL database
#143Earlier quoted context omitted.
Yep, you're not charged for egress.
B2 to Cloudflare also does not incur egress fees: https://www.backblaze.com/blog/backblaze-and-cloudflare-part... Backblaze B2 customers will be able to download data stored in B2 to Cloudflare for zero transfer fees. This happens automatically once Cloudflare is configured to distribute your B2 files.
I really don't care about the cost of storage. In my case it's the bandwidth costs that were killing me.
If it was available at the time, I would use R2 if only for simplicity.
If I was using Cloudflare Workers it would be another reason to use R2: I assume that it's easier to use and faster to use than any other storage system, since it's on the same network and written by the same people.
Also, exposing Backblaze via Cloudflare has it's issues. I ran into Cloudflare caching 404 responses from Backblaze and Backblaze being slow to make write visible.
So I would write into Backblaze and tried to access that key via Cloudflare proxy. While the write was acknowledged to my client it wasn't yet visible via http endpoint so Cloudflare would cache 404 response. I would have to clear the cache to fix and then I've added 5 min delay "just in case" to work around this.
Re: D1: Our SQL database
#144wow SQLite getting a lot of love these days https://tailscale.com/blog/database-for-2022 https://fly.io/blog/all-in-on-sqlite-litestream https://blog.cloudflare.com/introducing-d1
Well I don't think it's a good fit for regular service, exactly how do you handle 2 replicas of the same service talking to the same DB? The fact that it's just a file on disk limits the usage.
Re: D1: Our SQL database
#145All this recent hype around sqlite... sqlite is a great embedded database and thanks to use by browsers and on mobile the most used database in the world by orders of magnitude. But it also comes with lots of limitations. * there is no type safety, unless you run with the new strict mode, which comes with some significant drawbacks (eg limited to the handful of primitive types) * very narrow set of column types and o…
* the big one for me: very limited migration support, requiring quite a lot of ceremony for common tasks (eg rewriting a whole table and swapping it out) I don't know where this idea of having to swap a whole table in SQLite came from, but it simply isn't true. Over the last 13 years I have upgraded production HashBackup databases at customer sites a total of 35 times without rewriting and swapping out tables by usin…
`FULL OUTER JOIN` is the secret to diff'ing table sources. `MERGE` is just a diff operation + insert/update/delete statements to make the target table more like the source one (or even completely like the source one).
`FULL OUTER JOIN` is essential to implementing `MERGE`. Granted, one could implement `MERGE` without implementing `FULL OUTER JOIN` as a public feature, but that seems silly.
Sadly, the SQLite3 dev team specifically says they will not implement `FULL OUTER JOIN`[0].
Implementing `MERGE`-like updates without `FULL OUTER JOIN` is possible (using two `LEFT OUTER JOIN`s), but it's an O(N log N) operation instead of O(N).
The lack of `FULL OUTER JOIN` is a serious flaw in SQLite3. IMO.
[0] https://www.sqlite.org/omitted.htmlRe: D1: Our SQL database
#146CF people around, I would love to chat, if anyone is interested please reach out at: jp@javascriptdb.com
I'll be applying to this beta for sure!
Re: D1: Our SQL database
#147Earlier quoted context omitted.
Well I don't think it's a good fit for regular service, exactly how do you handle 2 replicas of the same service talking to the same DB? The fact that it's just a file on disk limits the usage.
Projects such as litestream and rqlite have this figured out.
Re: D1: Our SQL database
#148Good: Workers, KV, Durable Objects, Cron Triggers
Bad: Spectrum, Zaraz, R2, D1
Re: D1: Our SQL database
#149Earlier quoted context omitted.
Yep, you're not charged for egress.
B2 to Cloudflare also does not incur egress fees: https://www.backblaze.com/blog/backblaze-and-cloudflare-part... Backblaze B2 customers will be able to download data stored in B2 to Cloudflare for zero transfer fees. This happens automatically once Cloudflare is configured to distribute your B2 files.
Re: D1: Our SQL database
#150For a Cloudflare article, this one is surprisingly light on technical details. And for the product where it most matters. I'm guessing this is a single master database with multiple read replicas. That means it's not consistent anymore (the C in ACID). Obviously reads after a write will see stale data until the write propogates. I'm a bit curious how that replication works. Ship the whole db? Binary diffs of the mast…
> I'm guessing this is a single master database with multiple read replicas. That means it's not consistent Single master with read replicas is fully consistent if commits don't return until propagated to and acknowledged by replicas (the expense here being commit latency.)
Disclaimer: I am the creator of rqlite.