Those things all make databases a lot harder to scale. I respect that it must be a useful pattern, but I don't understand why one would want them so tightly coupled with state when all of it can be done safely in code that scales independently.
Conversation
If one has a new(er) database it's very popular to say "Feature X doesn't scale" or "Feature Y doesn't belong in the database". Folks have been doing it since MySQL 2.0. And then, mysteriously, these features become must-haves as soon as the DB in question offers them.
2
2
5
deja vu
Quote Tweet
Replying to @mjasay @jer_s and 2 others
Myth -> marketing debt, all companies must solve this.
When feature is missing: market that users don't need it.
Feature arrives: talk about the myths of missing features.
1
2
Call this a marketing SEV and have a post-mortem the next time it happens. Need to hold them accountable for the problems created by "you don't need that feature" turning into "oops, that feature is here now".
1
3
Why is it so hard for marketing to define the market as customers who are well served by our products and services right now?
2
If only it were this simple 🙁 ... I'm enthusiastic about , I'm happy to talk up my opinions on relational benefits. I don't trash Dynamo or others, and I can be excited when DDB adds transactions. And I'm happy to debate whether PG needs all the "features" Oracle has.
1
2
And, just for you , as soon as PostgreSQL adds a new feature that happened to exist in Oracle previously (like unbuffered direct I/O is working on), I'll make sure to change my story overnight and say everybody always needed that feature in PG 🤣
2
5
We always *wanted* unbuffered direct IO, we just couldn't have it because of the amount of maintenance required. There's a whole building of people in Redwood Shores that keeps that code up to date with changing hardware.
3
3
That's not really how I see it. Yes, there's always been a need for AIO + DIO. But before the quite fundamental shift towards affordable SSDs on a bus with enough bandwidth and low latency (i.e. NVMe SSDs), the cost / benefit calculation was fundamentally different.
2
5
Right. That's also why you hear much less hype about purely in-memory DB systems these days.
I've always said "An in-memory database is just one that lacks the ability to spill to disk."
1