Обсуждение: Alignment check

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
adrian.klaver@aklaver.com

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.

On 6/27/24 10:26, Marthin Laubscher wrote:
> 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.
> 

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
adrian.klaver@aklaver.com

On 27.06.24 18:07, Marthin Laubscher wrote:

> 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 
> 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.

Having no experience with it I can't comment on YugabyteDB. With respect 
to PostgreSQL on Kubernetes there are various solutions on how to run 
it, some of which are quite mature - that is, they have been around for 
quite some time, are used heavily and have a healthy maintenance 
community (see f.ex. postgres-operator [1]).

One IMHO problematic aspect of running postgres in one or more pods is 
that running a postgres cluster is already demanding as is. When a 
postgres cluster goes awry then there will be work awaiting you to get 
it all backup up and running without messing up user data... using a 
solution like postgres-operator puts another additional layer and 
wrapper around postgres so if things do not run well there's even more 
systems you have to handle. It might or might not help that you have 
additional layers doing stuff to the postgres service:

- pro: the additional software layers can contain more operational
   knowledge than you have and handle and fix operations better than you
   know how to do
- contra: or the additional software layers can hide, obscure, obstruct
   the lower layers and interfere with you trying to debug and fix stuff.

Backups and a tested procedure to get things back up and running from 
scratch can be useful then.

All that said, from operational experience: postgres by itself is very 
robust in taking care of preserving your data, so despite everything 
written above, usually you have to be messing up things **really hard** 
to make postgres lose data.

*t

[1] https://github.com/zalando/postgres-operator/

PS: Thanks to all of you that are taking care, that postgres is caring 
so well about the user's data!

I don't have any direct experience with Yugabyte (the databases I work
with are way too small to be on Yugabyte) but my older son does work
for them as an SRE, sometimes remotely when he's visiting us, so we've
talked about it a bit.  (It's actually the first time in 20 years I've
had much of a clue about what he's working with.)

On Thu, Jun 27, 2024 at 11:08 AM Marthin Laubscher
<postgres@lobeshare.co.za> 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
PostgreSQLcommunity 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
YugabyteDBbecause it matches my 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
versionsand do not support extensions in a way that’s useful to me. 
>
> 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
thosetwo topics from the these parts of the woods. 
>
> --- Thanks for your time – Marthin Laubscher