Pigsty is an open-source, batteries-included, local-first PostgreSQL distribution. The recently released v4.0 is an epic major version — a quantum leap in quality and capability.
With this release window, I finally did something I’d been thinking about for a while: switching Pigsty’s license from AGPLv3 back to Apache 2.0.
Here my first-person account: why I changed it, what it means, and my overall take on open source, ecosystems, services, and commercialization.
The Origin Story#
When Pigsty was born, it used Apache 2.0.
The motivation was simple: I built something I enjoyed using, open-sourced it so others could benefit, and hoped to push the industry’s PostgreSQL practices forward a bit. With that mindset, Apache felt natural — open, permissive, no drama.
Then came v2.0, and I switched to AGPLv3. The surface reason: some well-known projects had moved from Apache to AGPLv3, and Pigsty caught the “infection.” But honestly, that’s just the easy-to-explain version. I later researched it carefully: their AGPL wouldn’t actually “infect” Pigsty — I wasn’t linking to them as libraries or modifying their code.
The real reason: I’d started raising investment and building a company. With serious commercial responsibility came serious thoughts about protecting commercial interests. So I chose one of the most restrictive licenses in the open-source spectrum: AGPLv3. We also explicitly stated in our license and disclaimers: we wouldn’t pursue regular users; the enforcement effect would be equivalent to Apache-2.0; AGPL was more like “keeping an option open for extreme freeloading scenarios by cloud vendors.”
But practice proved: this option brought none of the protection I wanted, only new adoption friction.
AGPL’s Problematic Practice#
The first type of problem with AGPL is straightforward: it directly triggers “legal red lights” inside commercial companies. Many companies’ default policy on AGPL is: don’t touch it first — high cost, unclear risk, slow approvals. You can explain “I won’t pursue regular users” or “it doesn’t actually propagate in this case,” but often it doesn’t matter. Rules are rules, processes are processes.
I’ve had typical conversations like this: someone from a cloud database team chatted with me about solutions, and I suggested they self-host with Pigsty on their cloud servers. The response was blunt:
At last year’s PG Conference, I discussed this with friends from OAI. I suggested: “For running PG on Azure, why not just use Pigsty to self-host on their servers?” He told me: “Open source is fine to consider, but with AGPLv3, that’s a no-go.”
After having many such conversations, you realize: AGPLv3 creates adoption barriers for yourself — not technical barriers, but process barriers, and process barriers are usually harder to break through.
The second type of problem: AGPL may not actually stop the “freeloading” you imagined. Here’s a real delivery model that emerged: A cloud vendor/integrator sells compute and resources to a customer. The customer deploys Pigsty in their own environment. When they hit issues, they come to me for paid support. The other party indeed completed their delivery using Pigsty. But legally, AGPL has limited teeth against this “consulting / delivery / private deployment” model — the code isn’t being offered as SaaS, which doesn’t equal triggering the “cloud freeloading countermeasure” you imagined.
In many scenarios, AGPL is more like: scaring away people who want to seriously use your software, without necessarily achieving the effect you imagined. This change is even more evident in the data: since switching to AGPL, Pigsty’s open-source adoption growth visibly slowed — What used to fly like an exponential curve now crawls like linear growth. This “awkwardness” itself signals the problem.
Years ago, Martin Kleppmann (author of DDIA) made a similar point: GPL/AGPL don’t really solve the cloud-era value distribution problem. If you truly want to restrict cloud vendors, what you need often isn’t an open-source license, but a “source-available” system (ELv2, SSPL, BSL, etc.), or even a product strategy itself (like local-first, distributable, ecosystem lock-in), rather than hoping the GPL family will deliver justice in the cloud.
So the more I thought about it, the more certain I became: AGPL is neither open-source-friendly enough, nor effective enough against cloud. The worst of both worlds.
So Why Not ELv2 / SSPL / BSL?#
Since AGPL doesn’t work, a natural follow-up question is: you’ve been advocating “get off the cloud,” right? So why not just use ELv2 (Elastic License v2) — something that’s “basically Apache for normal users, but explicitly restricts cloud vendors” — and be done with it?
Honestly, I seriously considered it. Especially at this point in time: Pigsty is approaching “finished software” status. I don’t lack PRs, and I don’t need open-source collaboration to push features forward. The reality today is: give me an idea, and with tools like Claude, I can build it out remarkably fast. For me, the community’s most important value isn’t code contributions, but:
- Real-world scenario feedback and problem exposure
- Reusable templates and best practices
- Case studies, word-of-mouth, evangelism, and ecosystem connections
Under these circumstances, “do I actually need a strictly OSI-approved open-source license?” becomes a sharp question. But in the end, I didn’t go with ELv2. There’s only one core reason: that’s not what I want to build.
What I actually want is to make Pigsty “the Debian of the database world.” Debian didn’t become Debian by “restricting who can’t use it.” It did it through: openness, inclusivity, reusability, distributability, eventually growing into an ecosystem position — mainstream distribution, upstream, standard, infrastructure.
The Debian of Databases#
I said in my public talk “A PostgreSQL Distribution: Rooted in China, Facing the World”: Pigsty’s goal is to become the Debian of the PostgreSQL world — a globally-oriented, truly useful, distributable, reusable mainstream distribution.
My assessment: the next two years will be a window of dramatic change in the database world and software landscape. AI, agents, infrastructure paradigm shifts — these will reshuffle “who becomes the default choice.”
PostgreSQL has already become the Linux kernel of the database world, while the distribution wars are just beginning. This kind of historical window doesn’t come often. Pigsty already has a ticket to the game, and I’m not planning to miss this show.
To seize this window and become a mainstream database distribution, you don’t win by wielding licenses as weapons. You win by:
- Making users happy and stable
- Letting vendors integrate and redistribute
- Giving ISVs paths to profit
- Creating value for developers, ops, and DBAs
For this incentive structure to work, a permissive license is almost mandatory. It signals posture and sincerity: welcome to use, welcome to integrate, welcome to distribute, welcome to build your own version.
To put it more bluntly: welcome to “freeload.”
But let’s be clear about boundaries: take it and sell it, fine. Just don’t falsely claim it’s some “100% homegrown, built-from-scratch domestic database.”
Why Fear Freeloading in Open Source?#
Many people ask me: in an era where everyone’s moving from open source to “source-available” and licenses keep getting more restrictive, why are you going against the current back to Apache? Aren’t you afraid of being freeloaded? How will you make money?
My thinking is simple: if you’re afraid of being freeloaded and expect to monetize directly through licenses, then just don’t open source — sell commercial software instead; if you choose true open source, you have to accept its basic reality: it will be used, integrated, and redistributed. You should treat it as a gift to the world. Treat open source as a form of entertainment and public service — that’s closer to what it really is. As Linus Torvalds said in his autobiography — Just for Fun.
Of course, on a moral level, I’m not impressed by certain cloud vendors reskinning open-source projects to drive traffic and sell their own servers and services. But this trick doesn’t work on Pigsty — it’s not cloud vendors’ dish, it IS the cloud database’s money bowl itself.
Top cloud vendors all have their own RDS/PG services, deeply tied to their own cloud infrastructure. If they really wanted to turn Pigsty into RDS, it’d be awkward — that’s like using someone else’s flag to smash your own sign.
Though I advocate “get off the cloud,” that’s mainly aimed at cloud databases like PaaS. Getting down to IDC self-hosting is great, but self-hosting on cloud servers is fine too; Cloud IaaS, aside from cloud disks being really underwhelming, doesn’t have major problems — there are NVMe instance storage machines too, use them if they fit, no problem.
So for vendors and integrators who don’t have mature hosted PG services but want to make “self-hosted PG delivery” a capability, my attitude is clear: welcome. Making more friends is more important than “wielding licenses as a stick.”
New Positioning: From “Distribution” to “Meta-Distribution”#
Using a permissive license has another consideration — Pigsty’s positioning has evolved from “a PG distribution” to gradually becoming a Meta-Distribution.
Pigsty’s design philosophy from day one was — everything is customizable. You can easily achieve various customization scenarios through simple configuration according to your own needs. Pigsty provides a complete toolbox and infrastructure, plus the largest and most comprehensive binary extension distribution catalog and repository in the PG ecosystem. You can build your own sub-distribution based on Pigsty, just like how countless custom branches grew from major distributions like Debian/Red Hat in the Linux world.
A new project I’ve been working on recently: PIGLET.RUN (Pigsty Lightweight AI Sandbox Runtime) is an example, adding a Vibe Coding toolbox on top of Pigsty’s single-node template, letting you spin up Claude Code, VS Code and other full-stack services in the cloud with one click. This is a first-party Pigsty sub-distribution.
You can swap out the kernel, replace this PG kernel with your own; or if you’ve built some extensions, developed some software, package them in and make your own PG distribution. I think for PG kernel vendors this is a great thing — what used to be a bare-bones RPM kernel package now becomes “HA, backup/restore, monitoring, IaC, offline delivery” all included, customer value jumps an order of magnitude.
Actually in v3 we already provided the ability to use custom PG kernels. You can spin up several different flavors of PostgreSQL kernels with one click. Strictly speaking, support for each of these kernels could be a new sub-distribution. Percona TDE, Supabase, OrioleDB, PolarDB, IvorySQL, AlloyDB, etc. You can make them into distributions like PolarStyle, IvoryStyle, HaloStyle. You can even use Claude Code to write a MySQL Ansible module playbook inside and make a MysqlStyle distribution.
For the “meta-distribution” concept to work, the license must be permissive enough. Otherwise you’re saying “welcome to distribute” while writing “distribution triggers obligations” — ecosystems don’t grow that way. My ideal endgame: Pigsty eventually develops some kind of governance structure, maybe even a committee and co-building mechanism like Debian. Big goal, but big is interesting.
Key Timing: Finished Software#
Why switch back to Apache at v4.0 specifically? Because v4.0 is a milestone version — it’s reached “Finished Software” status.
If I use my personal peak capability as the 100-point baseline, then Pigsty itself has reached 90 points. For reference, I’d give AWS RDS about 80 points.
Of course I can’t say this myself without sounding like I’m shilling. So I specifically asked the SOTA AI trio (GPT, Claude, Gemini) to objectively and fairly analyze and give me a comparative assessment, and the results were basically like this:
This rating represents Pigsty’s performance level in mainstream AI perception, so the question becomes: If you’ve made a free product at 90 points, what happens to the paid 80-point services? So that’s about enough — push any further and forget killing cloud databases and competitors, I might kill myself too — after all, what I sell is expert consulting services that take the 90-point self-service free experience to 100 points.
Of course, I very much welcome ISVs and individual DBA experts to build their own commercial services on Pigsty. This market is huge, how could I eat it all? You serve your customers, I can provide upstream support — you handle what you can, escalate to me when you can’t. Isn’t that healthy ecosystem division of labor?
Business Model: Making Money Standing Up#
Many people are also curious: since it’s open source, how do you make money? A model I particularly admire is the path the VictoriaMetrics founder took.
This legendary programmer single-handedly built VictoriaMetrics, dominating the observability world on performance and quality. Then he started a company, mainly providing enterprise technical support, keeping a few professional modules in the enterprise edition. No fundraising, no pressure, living the good life. Basically Pigsty follows a similar playbook.
Pigsty also has a commercial edition — same codebase as open source, but supports more operating systems and older PG major versions. It includes a powerful CLI, DBA Agent, Skills and SOPs, plus a non-open-source test suite with various failure scenario cases — somewhat like SQLite’s approach.
But the commercial edition isn’t the point. Enterprises won’t pay for what you’ve already open-sourced — they only pay for actual value delivered — helping them take service quality from 90 to 100 points, customers are happy to pay for that. This includes warranties, Q&A support, edge case troubleshooting, and battle-tested experience running PostgreSQL at scales larger than OpenAI’s — Know-How knowledge and verification capabilities that won’t appear in AI training data.
At the end of the day, what I sell isn’t the product — the product is all open-sourced as a gift to everyone, what’s there to sell? What I sell is my experience and time — you can use Pigsty for free, but you can’t expect free consulting from me, right? — Fortunately with AI’s help, most of the time I just need to ask the right questions and judge the correctness of results, basically adding dozens of times leverage to my time, so day-to-day is still pretty relaxed.
If you’re using Pigsty and find what I’m doing helpful, subscriptions are also welcome. First, there’s commercial commitment and contract; second, it’s also a way to support software freedom and the open-source ecosystem.
Conclusion: Apache 2.0 Isn’t Compromise#
So to summarize, going from AGPLv3 back to Apache 2.0 isn’t me going soft, nor am I being naive.
This is a strategic choice: Pigsty aims to be the Debian of the database world — To achieve this, openness and inclusivity aren’t slogans — they’re engineering requirements. Reduce friction, expand distribution, build ecosystem.
Pigsty v4.0 is now officially released and available. I hope it helps more people enjoy PostgreSQL more easily: use it well, manage it well, save money, save headaches.
