public inbox for [email protected]help / color / mirror / Atom feed
Re: Alignment check 4+ messages / 3 participants [nested] [flat]
* Re: Alignment check @ 2024-06-27 17:03 Adrian Klaver <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Adrian Klaver @ 2024-06-27 17:03 UTC (permalink / raw) To: Marthin Laubscher <[email protected]>; [email protected] On 6/27/24 09:07, Marthin Laubscher wrote: > Hi, > > I don’t intend dissing or plugging anyone’s efforts or start a flame > war, but I’d like to get a sense of how the PostgreSQL community feels > about: > a) YugabyteDB, and > b) PostgreSQL on Kubernetes. > > For my application I’m deeply vested in Kubernetes as a pathway to being > cloud-agnostic and I have looked at YugabyteDB because it matches my And substituted a single platform dependence. > application’s (distributed) architecture more closely. > But not all the ways to run PostgreSQL on Kubernetes are created equal, > and YugabyteDB is really far behind on versions and do not support > extensions in a way that’s useful to me. Which now leads you to above. > > So seeing that I’ve taken the plunge to join the mailing lists at least > I’d love to hear any and all feedback on those two topics from the these > parts of the woods. > > --- Thanks for your time – Marthin Laubscher > -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Alignment check @ 2024-06-27 17:26 Marthin Laubscher <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: Marthin Laubscher @ 2024-06-27 17:26 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; [email protected] On 2024/06/27, 19:04, "Adrian Klaver" <[email protected] <mailto:[email protected]>> 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 Kubernetes is a "single platform" but it provides the same facilities in all of its guises from bare metal implementations to what you can rent on demand from public clouds. I've made peace with that being about as cloud-agnostic as 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 which would only make sense if it unlocked a massive performance upside. For all intents and purposes I'm already locked into PostgreSQL as my application's database because it's reliant on a custom extension like no other database would let me do. But single database isn't single vendor, as long as it's open source. If YugabyteDB did support my extension (I tried but they won't consider for their DBaaS/Managed/Yugabyte Anywhere/Yugabyte Aeon commercial product built on top of an old version of PostgreSQL) it would have meant that in a pinch I could rent additional capacity from their commercial offering while I expand my own points of presence. That kite's not going to fly though, so I'm back to dealing with all of the 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. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Alignment check @ 2024-06-27 17:34 Ron Johnson <[email protected]> parent: Marthin Laubscher <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Ron Johnson @ 2024-06-27 17:34 UTC (permalink / raw) To: pgsql-generallists.postgresql.org <[email protected]> On Thu, Jun 27, 2024 at 1:26 PM Marthin Laubscher <[email protected]> wrote: [snip] > So when you're done trolling me and my choices, Adrian didn't start this "conversation". > feel free to comment on the actual question. > YB says they are almost finished updating their system to the PG 15 (not sure which point release) codebase; it could already be in beta. Maybe your extension will work on the new version. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Alignment check @ 2024-06-27 17:40 Adrian Klaver <[email protected]> parent: Marthin Laubscher <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Adrian Klaver @ 2024-06-27 17:40 UTC (permalink / raw) To: Marthin Laubscher <[email protected]>; [email protected] On 6/27/24 10:26, Marthin Laubscher wrote: > On 2024/06/27, 19:04, "Adrian Klaver" <[email protected] <mailto:[email protected]>> 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 Kubernetes is a "single platform" but it provides the same facilities in all of its guises from bare metal implementations to what you can rent on demand from public clouds. I've made peace with that being about as cloud-agnostic as 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 which would only make sense if it unlocked a massive performance upside. For all intents and purposes I'm already locked into PostgreSQL as my application's database because it's reliant on a custom extension like no other database would let me do. But single database isn't single vendor, as long as it's open source. If YugabyteDB did support my extension (I tried but they won't consider for their DBaaS/Managed/Yugabyte Anywhere/Yugabyte Aeon commercial product built on top of an old version of PostgreSQL) it would have meant that in a pinch I could rent additional capacity from their commercial offering while I expand my own points of presence. That kite's not going to fly though, so I'm back to dealing with all of the 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. > Not trolling just pointing out what you described above. Sometimes simple is not and you end up going through all sorts of contortions to stick to the plan. Just an observation take it or leave as you like. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-06-27 17:40 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-27 17:03 Re: Alignment check Adrian Klaver <[email protected]> 2024-06-27 17:26 ` Marthin Laubscher <[email protected]> 2024-06-27 17:34 ` Ron Johnson <[email protected]> 2024-06-27 17:40 ` Adrian Klaver <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox