The growing dominance of PostgreSQL and the emergence of propriety solutions
As of 2025, PostgreSQL’s share of the relation database market sits at 16.85%, making it the second most used open source database after MySQL. It has become the preferred database choice of large, data-intensive organizations such as Instagram, Reddit, Spotify, and even NASA, and as of today, approximately 11.9% of companies with more than $200 million in revenue use PostgreSQL in production.
Naturally, new and existing database vendors have sought to capitalize on this trend. While precise numerical data comparing the number of proprietary PostgreSQL offerings today versus even five years ago is difficult to pin down, there are several indicators that suggest a significant increase in proprietary PostgreSQL solutions from both known players and emerging startups.
- Cloud Provider Adoption: Major cloud providers like AWS, Google Cloud, and Azure now offer managed PostgreSQL services with proprietary features and integrations, which was less common five years ago.
- Enterprise Solutions: The number of commercial PostgreSQL offerings has grown significantly in recent years, with multiple vendors, including EDB, reporting strong demand for enterprise-grade support, tooling, and managed services.
- Startup Innovation: New companies like Neon, Supabase, ParadeDB, PostgresML, and Tembo have emerged, offering innovative proprietary solutions built on PostgreSQL.
- Microsoft is launching DocumentDB, an open source NoSQL database compatible with MongoDB, built on PostgreSQL.
Moreover, this trend shows no sign of slowing. PostgreSQL’s support for in-demand, advanced data types—such as vectors for AI/ML workloads, JSONB for semi-structured data, time-series capabilities via Timescale, and PostGIS for geospatial data—makes it an attractive choice for organizations building next-generation analytics, AI, and big data solutions. Increasingly, enterprises are adopting PostgreSQL not only as their primary operational database but also as a backbone for complex analytical and AI-driven systems.
Distribution of companies using PostgreSQL by industries
Information Technology and Services
Computer Software
Internet
Financial Services
Marketing and Advertising
Telecommunications
Human Resources
Hospital & Health Care
Retail
Higher Education
Source: Enlyft
Propriety doesn’t necessarily mean bad… for now
As of 2025, proprietary PostgreSQL offerings aim to deliver enhanced functionality, enterprise-grade features, and commercial support layered on top of the open source core, making them appealing for mission-critical workloads. For organizations without the in-house expertise to manage and scale open source PostgreSQL in production, adopting a proprietary solution can be a reasonable and defensible choice.
But IT leaders should be thinking not just about today’s convenience, but where this trend may lead. Increasingly, companies with open source roots are moving to closed-source models as they seek ways to further monetize. Redis, for example, recently shifted its licensing model to the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1), restricting how its code can be used. In 2023, HashiCorp followed a similar path, transitioning the majority of its projects from the Mozilla Public License 2.0 to a more restrictive Business Source License (BSL).
Can MongoDB tell us where PostgreSQL is heading?
For an even more apt comparison, MongoDB was once celebrated as an open source alternative to relational databases, much in the same way PostgreSQL is now, but its trajectory has since taken a distinctly proprietary turn. MongoDB, Inc. has gone all-in on the DBaaS space, building a tightly controlled ecosystem around Atlas, its cloud database service. Community contributions and third-party services have suffered as a result, while licensing changes—such as the shift to SSPL—have made MongoDB effectively closed-source for many use cases.
MongoDB’s shift to a restrictive licensing model and vendor-controlled cloud platform mirrors the path of another industry giant: Oracle. Investors demanded sustained revenue growth, leading to changes that increased customer lock-in, raised licensing costs, and forced enterprises into expensive long-term commitments. MongoDB, once a beacon of open source, is now more Oracle than open. No doubt this move to a closed-source model is a key contributor to MongoDB’s decline in enterprise adoption.
Today, most of the conversation around MongoDB centers on moving away from the enterprise platform rather than adopting it. Perhaps the best reflection of this trend is a December 2024 blog post by Infisical — “an all-in-one platform to securely manage application secrets, certificates, SSH keys, and configurations” — titled The Great Migration from MongoDB to PostgreSQL. In it, they explain that while MongoDB served them well in their early days, they and their customers now “run into constraints around the capabilities and usability of MongoDB.” They also reported a 50% cost reduction on database costs when switching to open source PostgreSQL.
It’s a cautionary tale that adopters of proprietary PostgreSQL solutions would do well to heed. While PostgreSQL itself remains fully open source and is not governed by a single entity like MongoDB or Oracle, the surrounding ecosystem is steadily shifting toward vendor-controlled models and increasing lock-in.
Managed PostgreSQL services from major cloud providers come with proprietary enhancements that tie users to specific platforms. Enterprise-focused PostgreSQL vendors are introducing proprietary extensions and value-added services that, while beneficial, create barriers to true database portability. The same forces that transformed MongoDB—and Oracle before it—are now at play in PostgreSQL’s ecosystem.
The business risks of proprietary PostgreSQL reliance
For IT leaders, the risks tied to PostgreSQL’s commercialization extend far beyond database architecture—they can influence your organization’s entire technology. Proprietary PostgreSQL services may offer short-term convenience, but they often come at the cost of long-term agility. As cloud costs rise and licensing models evolve, decisions made today can become expensive traps tomorrow. Limited portability can derail cloud migration plans, complicate multi-cloud strategies, and hinder disaster recovery efforts. And with vendors increasingly pushing proprietary add-ons or aggressive product strategies—like MongoDB’s push to Atlas—there’s no telling what limitations may emerge next.
Vendor lock-in
Vendor lock-in is a top concern of PostgreSQL commercialization. Many proprietary and managed PostgreSQL offerings bundle proprietary enhancements that create dependencies on specific providers. Once embedded, it becomes difficult and costly to move away. You’re subject to the vendor’s terms—terms that can change at any time. This might mean unexpected shifts in licensing, rising support fees, or even redefinitions of resource units like CPUs. Oracle, for example, has long faced criticism for arbitrary pricing changes, aggressive renewals, and inflexible contracts.
The deeper the investment, the harder it is to leave. If you’ve embedded proprietary PostgreSQL into your infrastructure and sunk significant time and money into it, migration becomes a massive, multi-year undertaking that can cost millions more just to escape.
It should raise serious concerns that EDB—one of the largest proprietary PostgreSQL vendors—has published a blog post defending vendor lock-in as “not always a bad thing.” The author cites the expertise needed to build and maintain PostgreSQL in-house as a justification for choosing proprietary solutions (a point we’ll revisit later). But it’s worth asking: Who really benefits from that argument?
Delayed response to rapid market shifts
Being stuck also has broader consequences. Companies tied to outdated or niche technologies often stagnate. When your teams are locked into aging systems, they stop learning new skills and fall behind on emerging technologies. Over time, this erodes your technical foundation—and your ability to recruit talent who want to work on modern stacks. It becomes a downward spiral that limits innovation, agility, and the capacity to adapt to change.
Unpredictable cost fluctuations
Costs are also shifting. Many proprietary PostgreSQL vendors now use resource-based billing models that can escalate rapidly as usage grows. What starts as a cost-effective solution can quickly become a financial burden.
For example:
- Google Cloud’s AlloyDB for PostgreSQL charges based on vCPU and memory usage, with pricing that varies by region and configuration. While flexible, this model can drive up costs as workloads scale.
AWS Aurora PostgreSQL includes charges for I/O operations, which—if not carefully monitored—can significantly inflate total cost of ownership.
As an example of how quick costs can spiral out of control, Percona recently helped a customer—a membership and monetization platform—migrate off a costly DBaaS solution. Even after factoring the support fees of Percona Managed Services and Support, they cut infrastructure costs by more than 50% on a monthly basis.
Potential security and compliance risks
Security and control are additional concerns. Proprietary or fully managed PostgreSQL services reduce an organization’s visibility into infrastructure, security, and compliance settings. For companies in highly regulated industries, that loss of oversight can introduce serious risk.
Erosion of the PostgreSQL community ecosystem
Finally, if PostgreSQL continues to trend toward commercialization, its vibrant open source community—the engine behind decades of innovation—may lose momentum. Vendor-driven development could mean fewer community-led enhancements, slower adoption of open standards, and erosion of the openness that has long been PostgreSQL’s defining strength.
What’s the alternative?
What if you can’t DIY?
As discussed, proprietary PostgreSQL offerings can limit your flexibility, increase long-term costs, and compromise the open source principles that made PostgreSQL so appealing in the first place. But here’s the reality: Even if you want to avoid the risks mentioned above, building and managing a production-grade PostgreSQL environment entirely in-house may not be entirely feasible. That’s the crux of EDB’s argument, anyway.
Maybe your team doesn't have the time, deep expertise, or headcount to design for high availability, tune performance at scale, stay ahead of every upgrade, and manage compliance across complex infrastructure. But that doesn’t mean you have no choice other than to default to proprietary or cloud-managed options.
Percona for PostgreSQL offers a clear path forward for organizations that want to avoid the risks of proprietary PostgreSQL solutions without taking on the full operational burden of managing PostgreSQL in-house.
Percona delivers a fully open source, enterprise-grade PostgreSQL solution—complete with high availability, security, observability, and performance tooling—without proprietary constraints or surprise licensing fees. You retain control over where and how your database runs, with the flexibility to deploy across on-prem, cloud, hybrid, or Kubernetes environments.