As the year comes to a close and many of us start slowing down before the winter holidays, I find myself reflecting on patterns I’ve seen repeat, both as a customer and as someone working closely with the PostgreSQL ecosystem.

Looking back at software acquisitions over the past year, one might assume they only change logos. In reality, they often change roadmaps, priorities, and unfortunately all too often also the promises customers originally bought into.

I have experienced this more than once as a customer. Most recently, my team evaluated a product management tool that, shortly after being acquired, informed us we had a single month to migrate away. While I personally had not invested much time yet, colleagues had already moved documentation and workflows only to see that work become wasted effort. For those not familiar with product management, migrating all the product planning documentation is a huge effort and having it wasted is like erasing a month of your life.

One might say “business is business” and that customers can always take their money elsewhere. That may be true, but it does little to make customers feel safe or protected. In practice, it often leaves them confused about where accountability lies. Who should we blame when the original vendor no longer exists and the acquiring company is acting in its own strategic interest?

What struck me this year is how often these experiences echoed each other: across different tools, teams, and ecosystems. Unfortunately, I am now seeing similar patterns emerge in my professional focus area: PostgreSQL.

To be very clear, the PostgreSQL Community itself is driving an outstanding database, one that has been, and I am confident will remain, truly open source and community-developed. PostgreSQL as a project is healthy, stable, and thriving, and I hope it will thrive even more in the coming year.

That said, PostgreSQL is not just the database engine itself, but an entire ecosystem of vendors, extensions, and services built around it.

Over the past year, several important companies in the PostgreSQL ecosystem have been acquired and in conversations throughout the year this topic kept resurfacing. In recent prospective customer conversations, we increasingly hear from PostgreSQL users running mission-critical workloads on-premises who feel abandoned by their vendor. These organizations are being quietly nudged toward “modernization” paths that, in practice, resemble mandatory SaaS migration.

Having worked closely with MongoDB users for years, this pattern feels familiar. Since MongoDB Atlas became the primary strategic focus, many customers experienced similar pressure. What feels different, and what stood out to me most this year, in the PostgreSQL world is timing.

Teams often discover late in the renewal cycle that:

• Their on-prem PostgreSQL deployment is no longer strategic for the vendor
• Key components they depend on, which were never fully open source, are no longer available for renewal
• The implied options are to “move to the cloud” or rapidly find an alternative, even when migration planning is complicated by lack of source availability

This puts PostgreSQL customers in a difficult position: accept architectural change under pressure, or scramble to replace a trusted vendor while the clock is already ticking.

While recent conversations often reference Crunchy Data following its acquisition by Snowflake, this is not about a single company. The broader pattern has repeated across the industry, including infrastructure significant projects involving MinIO, Bitnami, HashiCorp, and Redis.

This raises a fundamental question for the PostgreSQL ecosystem and infrastructure software in general:

When a critical infrastructure vendor is acquired or changes licensing, who advocates for the customers that cannot move?

Open source is not just a licensing model or philosophical ideal. It provides freedom of choice, deployment flexibility, and risk mitigation. Recent community responses such as OpenTofu, OpenBao, and Valkey demonstrate a growing maturity and ability of open source communities to organize when freedoms erode.

It is disappointing to see these dynamics emerge around PostgreSQL, even though the database itself remains one of the most open source and community governed projects in the industry.

It is disappointing to see similar dynamics affect PostgreSQL, a database often considered one of the most open source driven projects in the industry. When PostgreSQL derivatives are impacted, the shadow inevitably reaches upstream as well.

If this post reaches teams who were not yet aware of these shifts and gives them more time to plan going into the new year, it serves its purpose. If you are running PostgreSQL in environments where SaaS is not an option, now is the time to ask difficult questions before renewal conversations start, not after options disappear.

As we head into a new year, I expect these conversations to become even more common. Acquisitions, licensing changes and cloud first strategies are not slowing down, but neither is the need for predictability, transparency and choice in how PostgreSQL is deployed and supported.

Looking ahead to 2026, my hope is simple: more open source products, more stable and predictable service offerings around them, and fewer last-minute surprises for the teams who depend on them every day.

We Want to Hear from You

I am curious:

• Have you seen similar shifts in PostgreSQL vendors post-acquisition?
• What is preventing you from moving to PostgreSQL community builds or alternative support models?

Let’s talk. You can reach me via:

• LinkedIn: https://www.linkedin.com/in/janwie/
• Email: jan(dot)wieremjewicz(at)percona(dot)com

Open Source isn’t a strategy, it’s who we are!

We are always open to your feedback. You can reach us at:

• Percona Community Forums
https://forums.percona.com/c/postgresql/25
• Via issues and discussions on Percona GitHub repositories

If there is an event we attend, focused on open source or not, don’t be a stranger, come chat with us in person! ∎