public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tomas Pospisek <[email protected]>
To: [email protected]
Subject: Re: Alignment check
Date: Sat, 6 Jul 2024 08:47:20 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

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!

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Alignment check
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox