PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni • Hacker News Board

Re: PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni

#41

Post by atombender » Tue, Dec 10, 2024, 11:10 AM UTC

harisund1990 wrote: post #40

atombender wrote: post #15

Earlier quoted context omitted.

I'm curious about this as well. I often see people talk about CockroachDB in production, but I don't think I've ever heard of anyone running Yugabyte. But it is definitely under active development. I found two threads discussing it from the past year: https://news.ycombinator.com/item?id=39430411 https://news.ycombinator.com/item?id=38914764 Yugabyte (as with CockroachDB and TiDB) is based on mapping relations to an…

> What we see in cases where someone takes Postgres and replaces the guts (Greenplum, Cloudberry, and of course YDB) is that it becomes a huge effort to keep up with new Postgres versions. The first upgrade is the hardest, but after that we will have the framework in place to perform consecutive upgrades much sooner. When the pg11 to pg15 upgrade becomes available it will be in-place online without affecting the DMLs…

I was referring to the effort by the developers to keep the forked codebase itself up to date with mainline. Isn't that the main hurdle?

My understanding is that you are patching a lot of core Postgres code rather than providing the functionality through any kind of plugin interface, so every time there is a major Postgres release, "rebasing" on top of it is a large effort.

That, to my knowledge, is why Greenplum fell behind so much. It took them four years to get from 9.6 to 12, and I believe that's where they are today.

Re: PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni

#42

Post by harisund1990 » Tue, Dec 10, 2024, 5:34 PM UTC

atombender wrote: post #41

harisund1990 wrote: post #40

Earlier quoted context omitted.

> What we see in cases where someone takes Postgres and replaces the guts (Greenplum, Cloudberry, and of course YDB) is that it becomes a huge effort to keep up with new Postgres versions. The first upgrade is the hardest, but after that we will have the framework in place to perform consecutive upgrades much sooner. When the pg11 to pg15 upgrade becomes available it will be in-place online without affecting the DMLs…

I was referring to the effort by the developers to keep the forked codebase itself up to date with mainline. Isn't that the main hurdle? My understanding is that you are patching a lot of core Postgres code rather than providing the functionality through any kind of plugin interface, so every time there is a major Postgres release, "rebasing" on top of it is a large effort. That, to my knowledge, is why Greenplum fel…

Cutis is an extension. That's the best you can get by being outside the core db. If you want true distributed architecture then you need to change the QO, DDL, transaction, even query stat components. At which point it ends up being a fork.

Yes, the merges are hard. But pg12 changed lots of fundamental things making it very challenging. Pg15 to pg17 should be much simpler.

Re: PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni

#43

Post by senorsmile » Thu, Dec 19, 2024, 9:06 PM UTC

hazaskull wrote: post #19

fweimer wrote: post #18

Earlier quoted context omitted.

Not sure about the CLA process, but the database is already under a restrictive, proprietary license: ## Free Trial Use to evaluate whether the software suits a particular application for less than 32 consecutive calendar days, on behalf of you or your company, is use for a permitted purpose. https://github.com/yugabyte/yugabyte-db/blob/master/licenses... It's not really clear what this means (what is a permitted pur…

Thanks. I think that only covers the commercial bits they run themselves though: "The entire database with all its features (including the enterprise ones) is licensed under the Apache License 2.0 The binaries that contain -managed in the artifact and help run a managed service are licensed under the Polyform Free Trial License 1.0.0." EDIT: formatting

It also mentions: > By default, the build options generate only the Apache License 2.0 binaries.

So, it seems like the proprietary builds are for the managed services that they host themselves, which makes sense.