Good product. Used it for a multi tenant implementation. Pretty easy to get started with, can get hairy before reaching operational excellence but when running, it’s pretty solid. I like it because it’s Postgres under the hood. Even extensions work. Happy self-hosting “customer”.
Why PostgreSQL High Availability Matters and How to Achieve It
31–40 of 86 posts
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#32Earlier quoted context omitted.
Or, uh, just self host.
What's the self-hosted Postgres HA story these days?
On self-hosted you can use the same as what cloud vendors are doing. Patroni or pg_auto_failover to manage single-primary + replicas. Maybe Neon to run an Aurora-like. CitusData... Azure did a lot around to get elasticity. Not easy to do the same. YugabyteDB on Kubernetes can be a cloud-native self-hosted solution
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#33Or, uh, just use AWS RDS Aurora.
This is a completely different story. YugabyteDB is about transparent sharding and shard horizontal scalability. Every table is split into tablets. A tablet can be thought of as a shard but one still thinks of a table as a whole. Each tablet is replicated. Replicas can be placed in different regions, even in different computing environments. Want to run it across clouds or span the cloud and bare metal? Ignoring the cost and minding latency, why not. It’s still logical single database with whole tables. Want to put some rows in selected regions? No problem, still one logical table. Very different from master-replica architecture.
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#34Earlier quoted context omitted.
What's the self-hosted Postgres HA story these days?
On self-hosted you can use the same as what cloud vendors are doing. Patroni or pg_auto_failover to manage single-primary + replicas. Maybe Neon to run an Aurora-like. CitusData... Azure did a lot around to get elasticity. Not easy to do the same. YugabyteDB on Kubernetes can be a cloud-native self-hosted solution
Which cloud vendors are using PGAF?
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#35Re: Why PostgreSQL High Availability Matters and How to Achieve It
#36Earlier quoted context omitted.
Google will never touch Citus because it is AGPL licensed[0], I wouldn't be surprised if the other cloud providers have similar policies. [0] https://opensource.google/documentation/reference/using/agpl...
I personally don't consider the AGPL to be a free software nor open source license. The burden it places on operating and using the software sufficiently violates freedom 0 in my view.
Yes infringing on the inherent freedom of corporations to maximize their profit margins is pretty awful
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#37one of the solutions which made it pretty simple for us to run postgresql in a ha environment (mostly in k8s, but works standalone as well) is zalandos patroni: https://github.com/zalando/patroni it's really solid and worked for us for a few years already. (it also comes with a haproxy config to have a single leader connection)
or for k8s their operator: https://github.com/zalando/postgres-operator (docker image: https://github.com/zalando/spilo) we've also tried other operators which were easier to get started, but they failed miserably (crunchyrolls operator is basically based on the zalando one)
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#38It’s amazing that this isn’t a solved problem, but we have all of this crazy language model stuff.
Unfortunately Spanner isn’t open source. Yugabyte and Citus are close but have annoying issues. Cockroach isn’t 100% compatible (and has its own issues) and things like FoundationDB which are truly HA and comparable to Spanner in terms of consistency and fault tolerance are not easily plugged into Postgres as the underlying storage engine since sadly it’s only a key value store.
edit: when I say close, I'm talking strictly about HA, not general functionality.
lately I've been thinking of using FoundationDB, which is closest to Spanner in terms of ACID and serializability and mvsqlite.
Then, I was thinking, since SQLite doesn't have online schema changes (nor does mvsqlite) to have a schema such as:
[UUID, Data, Version, CreatedAt, UpdatedAt]
In SQLite you can also create indexes on expressions so technically all of your JSON or Proto could also have indexes.
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#39Earlier quoted context omitted.
Google will never touch Citus because it is AGPL licensed[0], I wouldn't be surprised if the other cloud providers have similar policies. [0] https://opensource.google/documentation/reference/using/agpl...
I personally don't consider the AGPL to be a free software nor open source license. The burden it places on operating and using the software sufficiently violates freedom 0 in my view.
> define open source
denoting software for which the original source code is made freely available and may be redistributed and modified.
> agpl limitations
The AGPL License does not permit sublicensing of the code; that is, you cannot rework or add to the code and then close those changes off to the public.
considering these facts, your opinion is honestly ... pretty dumb.
There is nothing hard about forking the repository and then creating a readonly mirror of your working copy on a public github repo.
Re: Why PostgreSQL High Availability Matters and How to Achieve It
#40Very Interesting. Glossing over the article, it states HA within a Region. Curious if anyone is successful in running any Database with multi-region HA? How are you doing it?
Fauna can do multi-region HA, across clouds, serverless, with transparent sharding and replication. We get plenty of people struggling with not being able to do low-latency, performant, strict serializability distributed writes. It is designed to be a turnkey hosted solution. https://dev.to/luiseduardocolon/fauna-deep-dive-architecting... - Luis