pg_auto_failover VS plv8

pg_auto_failover makes it an absolute breeze. I cannot understand how it's not mentioned in the article.

I've been runnning it for 3 years with great success - https://github.com/hapostgres/pg_auto_failover/discussions/6...

Simplified and probably OK: pg_auto_failover - One Monitor/Witness node and minimum services otherwise. Good documentation to get started and not nearly as complex as Patroni.

There are tools that make managing such a system easier. Check out patroni, pg_auto_failover or PAF

This is /extremely/ uncharitable. It depends more on the project.

For example, both Go and .NET are very well written with comprehensible documentation. Many projects have also been absorbed by the Apache Foundation or other FOSS initiatives.

Every FANG has boat loads of teams working on umpteen different open source packages. The quality naturally varies.

Let me pick two more esoteric projects as a point of comparison.

Yandex Odyssey (https://github.com/yandex/odyssey) an advanced multi-threaded PostgreSQL connection pooler and request router. Figuring out how exactly and when to use this is not quite clear. There is no "getting started" guide for this package. There is barely any explanation for how it works or what it does.

pg_auto_failover (https://github.com/citusdata/pg_auto_failover) run by Citus (owned by Microsoft) monitors and manages automated failover for a Postgres cluster. This repo even has diagrams explaining the workflow and complete instructions.

Right, https://github.com/citusdata/pg_auto_failover has been on my reading list

My go to for this is https://github.com/citusdata/pg_auto_failover set up with ansible https://github.com/neuroforgede/pg\_auto\_failover\_ansible

pg_auto_failover github | readthedocs | ytube

a bit more than an experiment at this point. pljs, even in its early state, has some very good results: https://github.com/plv8/plv8/issues/531#issuecomment-1627883...

passing through v8's javascript/c++ membrane has always been painful, and appears to be getting worse.

From here you'll write a send_email function in Postgres that calls the API. I initially wrote the entire function in PLpgSQL and spent an entire day to get it debugged and working. And even then I wasn't happy with it. In my opinion that language is unintuitive and difficult to learn and debug. I switched over to PLV8, an extension for Postgres that supports writing functions in Javascript. It takes one click in the Supabase UI to enable this extension, and it will save hours and hours of time.

You jest, but the evil geniuses at plv8 have already done it for Postgresql.

To be honest I haven't used it, but I've extensively used pl/pgsql and a little pl/ruby, and know that https://plv8.github.io/ exists - it might be what you're looking for and it's on my list of things to play with

but, let's take your straw man a little further. let's suppose that all of the actual parsing is done for you already, and all you're doing is iterating through the data structure, creating objects through the c++ api, and calling it good. that should be faster than calling the c++ JSON.parse(), shouldn't it? since we don't have to actually parse anything, right? no, it's actually much slower. you can see this in action at https://github.com/plv8/plv8/blob/r3.1/plv8_type.cc#L173-L60...

again, we're not talking about whether javascript in an interpreter is faster than c++, we're talking about whether v8's api causes enough slowdown that some workloads that require a lot of data between c++ and javascript are slower than the same workload that requires very little data between c++ and javascript ... because passing through v8's c++/javascript membrane is slow.