Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D1: Our SQL database

blog.cloudflare.com

Post reply on HN
Print view View original

171–180 of 241 posts

Re: D1: Our SQL database

#171

Post by systemvoltage »

pygy_ wrote: post #167
systemvoltage wrote: post #163

Earlier quoted context omitted.

People want to change Chess to red/blue. I'll continue to play with white and black pieces. This is a slippery slope of destroying the society by being hyper sensitive about things that no one really means. Absolutely hate this and fills me with disgust that people obssess over this kind of petty things. Life is beautiful. Enjoy it. Be kind to others that have zero intention of offending you.

The person you're replying to is very kind and considerate. They're not assuming people using the problematic terminology do so with the intention to harm. They are, however, mindful of its negative effects, hence the gentle reminder.

The person I am replying to is very kind indeed. The rest of society obsessed with this political correctness madness are extremely hostile, engaging in shaming and generally have sadistic vibes of oppressing people with their moral superiority – which has zero basis except they discovered a new offending word to pile up on others.

This needs to stop IMO.

Re: D1: Our SQL database

#172

Post by zozbot234 »

ctur wrote: post #154

Quoted post unavailable.

> I see a lot of use of the "master/slave" terminology in this thread.

Hey, some people are still hosting their databases on clunky old IDE hard drives! Let's not be insensitive to their lived experience for the sake of technical novelty.

Re: D1: Our SQL database

#173

Post by unraveller »

infogulch wrote: post #54

Very cool! Glad to see all the love for SQLite recently. One thing I've noticed that many commenters miss about read-replicated SQLite is assuming that the only valid model is having one , giant, centralized database with all the data. Lets be honest with ourselves, the vast majority of applications hold personal or B2B data and don't need centralized transactions, and at scale will use multi-tenant primary keys or m…

I guess the first answer is: similar to Durable Object limits (unlimited databases / 50 GB total) since they alluded to those abilities more so than a simple file stored on R2 (only for backups).

Re: D1: Our SQL database

#174

Post by peterhunt »

kurinikku wrote: post #6

wow 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

SQLite is great but it's way overhyped and abused on HN. People are very eager to turn SQLite into a durable, distributed database and it's really not meant for that, and by going down that road instead of using something like MySQL or Postgres you're missing out on lots of important functionality and tooling.

I only say this because I have made this mistake at my previous startup. We built these really cool distributed databases on top of a similar storage engine (RocksDB) plus Kafka, but it ended up being more trouble than it was worth. We should have just used a battle-tested relational database instead.

Using SQLite for these applications is really fun, and it seems like a good idea on paper. But in practice I just don't think it's worth it. YMMV though.

Re: D1: Our SQL database

#175

Post by adventured »

nwsm wrote: post #159
systemvoltage wrote: post #155

Earlier quoted context omitted.

No one really means anything ill and this political correctness madness needs to stop.

Quoted post unavailable.

> If we can avoid terminology that is painful for others, why shouldn't we?

Because other people's feelings shouldn't be treated as important as they have (relatively recently) been elevated to be, particularly in the very dysfunctional and broken US culture.

Ideally we start stinging the soft US culture with a lot more political incorrectness. It's not a benefit for society to be so weak on such trivial matters as offensive terminology. Which is exactly what will follow this era of political correctness: inevitably the pendulum will swing back the other direction. We're due for an aggressive era of rebellion against the censorship and political correctness brigades.

Re: D1: Our SQL database

#176

Post by judge2020 »

pygy_ wrote: post #165
judge2020 wrote: post #157

Earlier quoted context omitted.

While the blog does use "primary", people are saying "master"/replica, much like how redis refers to their architecture[0]. In fact, ctrl-f "slave" only brings up your comment. 0: https://redis.io/docs/manual/replication/

"Master", however, is as prevalent as "primary" in this discussion "slave" is the implied counterpart. It would be better if we completely abandoned that terminology.

Out of all the comments that use the term "master" as of right now[1-5], the first three specifically use the term "replica" while the 4th and 5th use the verb "replicate" (in the present tense and past-tense).

1: https://news.ycombinator.com/item?id=31341392

2: https://news.ycombinator.com/item?id=31341661

3: https://news.ycombinator.com/item?id=31340318

4: https://news.ycombinator.com/item?id=31340169

5: https://news.ycombinator.com/item?id=31342145

Re: D1: Our SQL database

#177

Post by samatman »

peterhunt wrote: post #174
kurinikku wrote: post #6

wow 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

SQLite is great but it's way overhyped and abused on HN. People are very eager to turn SQLite into a durable, distributed database and it's really not meant for that, and by going down that road instead of using something like MySQL or Postgres you're missing out on lots of important functionality and tooling. I only say this because I have made this mistake at my previous startup. We built these really cool distribu…

I accept that you learned a lot about the limits of combining RockDB with Kafka, especially in the exact way you combined them.

This might have limited utility if the goal were to combine RocksDB with something else. And even less for SQLite and something else.

The big push of interest in SQLite serverside isn't driven by people who have never set up pgbounce, but rather by developers who have both read the SQLite docs very carefully and have used the library extensively, and know what it's good for.

Re: D1: Our SQL database

#178

Post by samatman »

pygy_ wrote: post #165
judge2020 wrote: post #157

Earlier quoted context omitted.

While the blog does use "primary", people are saying "master"/replica, much like how redis refers to their architecture[0]. In fact, ctrl-f "slave" only brings up your comment. 0: https://redis.io/docs/manual/replication/

"Master", however, is as prevalent as "primary" in this discussion "slave" is the implied counterpart. It would be better if we completely abandoned that terminology.

No post body was provided.

Re: D1: Our SQL database

#179

Post by at_a_remove »

nwsm wrote: post #159
systemvoltage wrote: post #155

Earlier quoted context omitted.

No one really means anything ill and this political correctness madness needs to stop.

Quoted post unavailable.

Because it is being used for manipulation, falsely. "Oh, oh, this hurts me! I cannot bear it!"

Recollect Emory University, in 2015, when someone wrote "TRUMP 2016" in chalk on the sidewalk. "Traumatized" protestors shouted "You are not listening! Come speak to us, we are in pain!" It's manipulation, pretending to be hurt. These people weren't locked in some kind of perpetual seizure for the four years of the Trump presidency, wailing in continual agony. It was a show.

Re: D1: Our SQL database

#180

Post by unraveller »

the_duke wrote: post #58
vlovich123 wrote: post #42

Earlier quoted context omitted.

D1 does not throw away consistency. It’s built on top of Durable Objects which is globally strongly consistent.

I wish the post had provided some more technical details. It's more of a "quickstart" than a peek under the hood.

I'd like to see some up front D1 & R2 benchmarks (read/write/iops). I can't judge invocation cost value until I can judge my use case performance. Here's hoping its -gt NVMe raid 10 under the hood of D1 as some big SQLite reads suffer under slow storage.
Post reply on HN