I wrote recently a piece [0] on why I believe you should run your databases in Kubernetes. FYI.
[0]: https://thenewstack.io/kubernetes-will-revolutionize-enterpr...
2,486 karma · joined June 4, 2014
[0]: https://thenewstack.io/kubernetes-will-revolutionize-enterpr...
Thank you for sharing so interesting data on the usage. This is very surprising to me, though. At least coming from my background (company providing Postgres Professional Services) we see much bigger deployments usually.
In any case, I expect servers to have replicas for high availability. So even an 8-core server would count for a total of 16 or 24 cores for a 2-3 node cluster, isn't it? And then this multiplied by the number of clusters that you have.
Some of our customers run 1,000+ cores on a single cluster. Or some others which run dozens of clusters, where each cluster is 3 nodes, with nodes in the range of 16 or 32 cores. That all adds to thousand-plus cores and arriving to the 6-7 figures (list price) that I was referring to. It may be surprising to me that in the SQL Server world deployments are significantly smaller. But very useful information!
What I believe is that for sure there's a very interesting use case here. AFAIK Amazon always makes decision based on customer requests and data they have. They have both Postgres and SQL Server on RDS. And if they created Babelfish and published it as a managed service, it's probably because there are a significant number of customer requests. Whether that is licensing savings, license/compliance uncertainty or anything else, I don't know for sure.
At $14K/core [0] for the Enterprise edition, it doesn't fit exactly on my definition of cheap. Sure, it's 1/4th of Oracle's price, but still translates to 6-7 figures for even small deployments, which again is not cheap to me.
But I guess the main attractiveness for current SQL Server uses might be more on the licensing terms/compliance problems than the cost. Just trying to understand how to license SQL Server and how cores are counted already requires you to read a 42-page guide [1]. The risks associated from incorrectly purchasing licenses for your SQL Server cluster(s) may be a compelling reason to jump into open source with minimal migration costs (at least compared to migrating directly to Postgres or any other open source database).
[0]: https://www.microsoft.com/en-us/sql-server/sql-server-2019-p... [1]: https://download.microsoft.com/download/e/2/9/e29a9331-965d-...
I already blogged about it when it was announced on December last year [0]. Adding SQL Server compatibility opens Postgres to new users, use cases, markets. It makes one of the most general-purpose databases to reach even more "purposes".
I hope work and discussions to integrate this upstream will start soon and will be fruitful. It won't be easy, but I believe it would be definitely worth the effort.
[0]: https://www.ongres.com/blog/aws_announces_open_source_postgr...
Yes, indeed we have considered doing a TF module for the configuration management API :)
First of all, congrats for the project.
As you probably know, you and any other user can indeed manage Postgres configurations, in any environment, via an API. See the "MANAGE" section in https://postgresqlco.nf/ Essentially, a hosted "Git repository" for Postgres configurations.
Postgres is trivial to install: $ apt-get install postgresql # will get Postgres installed on your laptop. But would you deploy this Postgres to production? You probably want to add connection pooling, high availability, monitoring, log management, backups… you need a Stack of components around Postgres, from its ecosystem, to reach production readiness.
At OnGres we have been providing Postgres Professional Services for years. We love IaC (Infrastructure as Code). One of our realizations was that it was next to impossible to create a “single IaC package” that would contain Postgres and its Stack of components, that would work on any environment. There are just so many different compute, storage and networking components, with different APIs.
So we asked ourselves: is there any “abstraction layer” for distributed infrastructure? The answer was Kubernetes. Kubernetes APIs allowed us to create a single deployable Postgres package, that contains Postgres itself and all its necessary Stack, and run --almost-- anywhere.
Let me ShowHN you today StackGres 1.0.0 [02], a Postgres-aaS on Kubernetes, that allows you to create production-ready Postgres clusters on the cloud or on-prem. StackGres contains the full Stack of Postgres components needed for production:
* High availability and automated failover, using Patroni. Managed DNS endpoints for the primary (rw) and replicas (ro, load balanced) connections.
* Built-in, enabled by default connection-pooling.
* Configurable automated backups with retention policies.
* Prometheus metrics exporter, with auto-binding. Customized Postgres metrics, Grafana dashboards and Postgres alerts.
* Expertly tuned default configurations --which you can optionally override.
So far, this may be “table stakes” as of today. We wanted to provide more. StackGres has introduced significant innovations --while keeping the same Postgres core “boring”-- such as:
* Using Envoy to proxy all Postgres traffic. In collaboration with the Envoy Community, we developed [03] the Postgres filter for Envoy [04]. We use it to add additional monitoring (by inspecting the wire protocol) and to terminate SSL!
* A fully-featured Web Console. It supports everything StackGres can do. And yes, it has a dark mode ;)
* A system to push all Postgres and Patroni logs from the pods to a central server. This central server is a separate, StackGres-managed Postgres database with Timescale for large volume and high velocity logging. Query your logs with SQL or from the Web Console.
* Fully automated “Day 2” DBA operations, including: minor and major version upgrades, controlled cluster restart, container version upgrades, vacuum, repack and even benchmarks!
* A system to dynamically load Postgres extensions into the containers. This allows us to ship lighter containers, while supporting potentially hundreds of extensions --120 as of now [05], with many more to come in the future. Precisely yesterday I gave a presentation at Kubecon about this extension system. You can review the slides in [06].
StackGres is designed to be easy to use, even by non Postgres experts. Our CRDs [07] are declarative and very high level, abstracting away from Postgres low-level details. And you can use them interchangeably with the Web Console for a point-and-click UX.
StackGres is Open Source (AGPLv3), developed on GitLab [08] (congrats for the IPO!), with public issues and dashboards [09], containing detailed descriptions and open for anyone to chime in. Any code or documentation contributions are very welcome, as well as issues and ideas! With more than 4,500 commits, it’s a large project (40K Java SLOCs and several other Ks between JS and Shell) that took more than 2 years to develop.
Please give it a try, share your thoughts here, and when this ShowHN thread ends feel free to follow up on our Slack [10] and/or Discord [11] public channels. Thank you!
[01] https://ongres.com
[02] https://stackgres.io
[03] https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-...
[04] https://www.envoyproxy.io/docs/envoy/latest/configuration/li...
[05] https://stackgres.io/extensions/
[06] https://kccncna2021.sched.com/event/lV1u
[07] https://stackgres.io/doc/latest/reference/crd/
[08] https://gitlab.com/ongresinc/stackgres/
[09] https://gitlab.com/ongresinc/stackgres/-/issues
You acknowledge, yet fail to see the problem. That these two entities overlap so much is a very bad thing, and definitely a liability if things turn bad from a legal perspective.
This is one of the issues I have been calling for reform for many years. I understand how things evolve; but when problems are recognized, then it's time to fix them.
If we all agree (we do!) that a single entity should have all the IP for the project, that's what needs to be. "cosy" is not a valid reason for keeping the current status quo.
Actually, if you read the terms how our proposal to Core, we're ready to hand the trademarks if a not "cosy", but a solid, legal structure is established. Which doesn't exist today. And we consider this puts the project at risk.
And nobody has asked them, neither sued them, for this. Indeed, PostgreSQL Europe joined together with Canada to sue Fundación.
But PostgreSQL Europe is no different from Fundación: just a Postgres NPO.
Yes, this is the case. Indeed, many times. I have personally voiced many concerns about different aspects of the governance and workings of the Community. And in 2019 a very clear and significant case was raised when some dispute over IP (a domain name) surfaced. In this case, we declined used of the domain name following Core's request, but raised --again-- concerns over the governance of Postgres.
The answer to all of these requests? Outright denial. Silence. Nada. There is no willing to change anything. Also one year later I voiced some of these concerns publicly (https://postgresql.fund/blog/is-it-time-to-modernize-postgre...). Same outcome.
So yes, I have at a personal level and we have at the Foundation level tried everything we believed could be done. And we perceived trademarks are more at risk with PAC and PEU than us, and we saw that some were not registered, so we proceeded to protect them and offer them openly to the Postgres Community (https://postgresql.fund/trademarks).
And as stated publicly, we're ready to transfer them to a single entity. It just can't be the current ones.
But there hasn't been any other previous communication. Our first notice from them, as detailed in the post, was from their lawyers.
So there has been no attempt on their side to come to even an amicable conversation. I offered that --but was denied.
> And honestly, even the domain name postgr.es is confusing.
That domain is held by PostreSQL Europe. So according to your argument, they shouldn't hold it.
> From the PostgreSQL EU website (as linked by you), these are their specific trademarks:
That they are more or less confusing is something I may agree with. But I don't see why it may change the subject matter: if the agreement would be that only a single entity would hold them, so be it. PEU can't definitely do that, under no circumstance.
"Funnily" enough, PEU is also one of the entities suing Fundación in the courts. Indeed, on the very first letter, as our post mentions, they are presented with PAC as if they were part of the same: "in representation of both the PostgreSQL Community Association of Canada and PostgreSQL Europe ("individually and collectively")".
So your argument that PEU's are not confusing is not what is at stakes here. It is that two entities, unrelated and separated, want to be the steward of the trademarks in Postgres. And if a third one tries to help, covering some observed gaps, it is sued by both. That is potentially collusion.
> And I'm sorry, but the global stability of the Postgres project is far more important than whatever good intentions you had.
I agree. But then why https://www.postgresql.org/about/news/trademark-actions-agai... is posted publicly? If the matter is in the courts (as it is), why is it needed to bring it publicly? We're happy to defend ourselves in private and in the public if needed, but I don't see what they win by this, and I see how it goes against the whole Community.
I'm sure you have read in our post that "The PostgreSQL Association of Canada; Postgres Europe; and Fundación PostgreSQL will transfer, permanently and irrevocably, all domain names, trademarks and other IP assets to the new NPO. New, clear and non discretionary rules will be established to allow fair use of the PostgreSQL trademarks by any stakeholder.". So it's not that we're unwilling to transfer the trademarks to the "Community". It's just that we disagree what the governing bodies of that community should be, believing that the current ones are a great liability and need urgent reform.
Of course, they don't want reform, so they chose to bash us publicly when the matter is in the courts. Who's harming the Community then? Are the trademarks currently registered by Fundación not offered to the public, with indeed less restrictions than PAC and PEU's? (https://postgresql.fund/trademarks).
We value team membership by their abilities, and values. Those may prove better at building Community that C programming ability.
Yet you are wrong when you state that Core Team holds trademarks. Core is not even a legal entity (the main mistake that I've been voicing for years; it should).
Instead, there's a "loosely associated" association in Canada (PAC), with a governing board as opaque as Core, that holds the trademarks. Let's even assume this is OK.
But then, PEU (https://www.postgresql.eu/) also holds trademarks! Why? Is PEU an "official" association in any way? (if so, there should be a process and rules to become official, but there aren't).
So if Core (read: PAC) is the only one who should hold the trademarks, why is not Core/PAC also suing and publicly bashing against PEU? What makes PEU special? What makes legally PEU different from other Postgres NPOs?
I've been asking this question for years, including many times during this "debate" with Core/PEU/PAC about the trademarks. No answer.
In any case, read the will: Article's 3 and 4. Do you disagree with them? Do you think they are bad for Postgres, or good?
Do you support that will?
Because if so, this will is a powerful asset of this NPO, as it cannot be (significantly) changed. However, Core's will, as well as PEU and PAC's will, could be changed in a way that would go against Postgres.
As the post states, with dates, there has never been any communication from them to discuss this matter. Only through laywers, since day 0. Even some of them, long-time personal friends of mine, where shut of and were banned to communicate even at a personal level. Not even with laywers present.
There was no need to make all this public. This clearly hurts the Community.
As the post says, there's no explanation to why PEU, who is as legit as any other non-profit Postgres association, including Fundación PostgreSQL, can hold trademarks and not being sued and publicly bashed.
If PEU can hold trademarks, why can't Fundación? Conversely: if there should be one trademark holder (and we agree, read the proposal we submitted to them which got no reply!) then it should be a legal entity with more solid grounds than current Core's Group (which has no legal entity behind) or PAC, which is a quite opaque association too.
* Every action of its board is supervised by the Ministry of Justice. * No action or change to the status can go against the initial will (which is part of the Estatutes, in particular Articles 3 and 4). Even if anyone would try to change them, they could only be done in a way that respects them. This is what is called "the founder's will".
So it's a very protective non-profit, which always needs to serve the public good and the founder's wills, which are Articles 3 and 4. And there's even public supervision for this.
We believed this form of a non-profit is much stronger and better to protect a Community like Postgres from potential rogue actors.
As an aside, we contemplate honorary (non-voting) members. We believe is a good thing. I'd also propose the same for Core --I believe at least Bruce Momjian should be named as such.
Yet this is public (as in the public registries).
Please contact us if you want further information.
OP here.
Actually, a "Fundación" in Spain is an entity specially scrutinized by the Ministry of Justice, and could never to anything like this. It is meant to be for the public good.
Besides, this very same question could have been applied to the Core Team members that are employees of EDB and/or Crunchy, two entities that control the majority of Core. And Core is not even a non-profit, it's nothing (there's no legal entity behind). Or the PostgreSQL Association of Canada, which is an association which could definitely grant exclusive trademark use to a given entity, as it is not scrutinized by a country's Ministry, as a Fundación in Spain is.
But it's also wise to review the default_statistics_target being used, that autovacuum is running frequently enough (which does autoanalyze), that the analyze thresholds are also properly tuned...
Thank you for mentioning https://postgresqlco.nf Team member here :) All these parameters mentioned here are well documented there, with recommendations.
Also, have you tried the Tuning Guide? (https://postgresqlco.nf/tuning-guide)
"Harmful" conveys enough information to raise awareness of a topic which might not be usually considered. Both examples show this pattern: schema-less is often considered a good thing, when it is not (in Stonebraker's and my opinion); also subtransactions are usually considered a good thing, while the OP shows they can have notable negative effects (of diverse nature) in the database.
(edit, typo)
[1] https://www.enterprisedb.com/blog/schema-later-considered-ha...