On 2024/06/27, 19:04, "Adrian Klaver" <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:
> And substituted a single platform dependence.
Even bare metal can lock you in without some abstraction layer between your code and the hardware. It's true that
Kubernetesis a "single platform" but it provides the same facilities in all of its guises from bare metal
implementationsto what you can rent on demand from public clouds. I've made peace with that being about as
cloud-agnosticas I can realistically achieve.
> Which now leads you to above.
To me that's a good thing. I've got no time for puristic idealism. It's a pragmatic choice which always involve
compromises."Compromise knowingly", an old manager of mine used to say.
Yugabyte, if I did go with it, would have been a tough choice because it would lock me into them as database vendor
whichwould only make sense if it unlocked a massive performance upside. For all intents and purposes I'm already locked
intoPostgreSQL as my application's database because it's reliant on a custom extension like no other database would let
medo. But single database isn't single vendor, as long as it's open source. If YugabyteDB did support my extension (I
triedbut they won't consider for their DBaaS/Managed/Yugabyte Anywhere/Yugabyte Aeon commercial product built on top of
anold version of PostgreSQL) it would have meant that in a pinch I could rent additional capacity from their commercial
offeringwhile I expand my own points of presence. That kite's not going to fly though, so I'm back to dealing with all
ofthe data distribution logic in my application layer itself.
So when you're done trolling me and my choices, feel free to comment on the actual question.