for each there are conditions, including number of contributors, number of companies oficially backing it, etc.
As the project was open till now, there were other open apps based on it, and currently unable to maintain both the main project and their own ones.
eventually with APRS (amateur packet radio)
a. integrations with other systems which do not have very strict latency constraints
b. replication to disaster recovery site
The benefits are listed (between lines) in both article and below.
Price is is usually still treating those pods like pets:
- one pod per k8s node (taints&node selectors) - special sizing & tunings of the targeted nodes (resources, kernel params, etc)
- one LB per Pod. yes, costly and against what you would expect, but that's what is required for a bullet proof deploy. (delay is not always there, especially in clouds, LB have super efficient implementations (especially gcp)
- bullet proof storage, with the required performance computed in your sizing phase.
But, above all, I would warmly recommed anyone to first do their best to use cockroachDB (or yugadb if you like more) instead. The benefits of distributed/horiz scaled DB usually overcome the effort of moving to it (which should not be big as it's using same pg client/protocol). And it's free if you don't need enterprise features like partitions, etc.