Stop Using Docker for Postgres. There’s a Better Way (But It’s Also a Trap)

You’ve been there. You just need a quick Postgres instance for a test. Nothing fancy — a throwaway database that lives for ten minutes and dies quietly. So you reach for Docker, and twenty minutes later you’re debugging a port conflict, a volume mount, and a Compose file written by someone who clearly hates joy.

Or maybe you use Homebrew. Or apt. Or some cloud-managed thing that bills you $0.02 forever for a database you used once. Either way, the ritual is the same: you spend more time installing the database than writing the code that talks to it.

Now imagine this instead:

pip install postgresql-bin

That’s it. No Docker. No Brew. No apt. No YAML file with seventeen indented lines. Just pip — the thing you already have, the thing you already trust, the thing that already knows your platform and your Python version and your virtual environment. One command, and you have a working Postgres binary ready to spin up and tear down.

Every developer’s deepest fantasy is a world where setup costs zero minutes and zero brain cells. The moment you deliver that, you’ve won their heart — and their dependency tree.

The project, created by developer leontrolski and hosted on GitHub, does exactly this. It packages a PostgreSQL binary inside a Python wheel and distributes it through PyPI. You install it. It works. You get a Postgres instance for testing, you run your tests, you throw it away. The friction that once consumed your afternoon now consumes a single shell command.

But here’s where it gets interesting — and by interesting, I mean the kind of interesting that makes Python ecosystem maintainers wake up in a cold sweat.

PyPI was never designed for this.

PyPI is the Python Package Index. Emphasis on Python. It exists to distribute Python packages — code written in Python, extensions compiled for Python, wheels that serve Python programs. It is not a generic software distribution platform. It is not npm. It is not a CDN. And yet, here we are, using it to ship a compiled C database binary that has nothing to do with Python at all.

The Python community is already debating this. A thread on discuss.python.org raises the exact question: should PyPI be used as “a generic storage platform for binaries”? The answer, depending on who you ask, ranges from “absolutely not, this violates the spirit of the ecosystem” to “well, it works, doesn’t it?”

When a package manager becomes too convenient, people stop caring what it was originally for. Convenience is a gravity well — everything gets pulled in, and nobody asks permission.

And this is where the story gets bigger than Postgres.

What leontrolski did with Postgres is a microcosm of something happening across the entire software landscape. Package managers are becoming universal distribution channels. npm ships CLIs written in Go. Homebrew ships GUI applications. Cargo ships system utilities. And now pip ships database binaries. The walls between language ecosystems are dissolving — not by design, but by developer pragmatism.

Every developer who has ever cursed a Dockerfile understands the appeal. When you’re deep in a Python project, you don’t want to context-switch into Docker’s universe. You don’t want to learn Brew’s formula syntax. You want to stay in pip, because pip is home. The tool you already know is always faster than the tool you’d have to learn.

But this convenience comes with a cost that’s invisible until it isn’t.

First: binary bloat. PyPI already struggles with package sizes. Now imagine a future where every non-Python tool that a Python developer might need — Redis, SQLite variants, Node runtimes, ffmpeg — gets packaged as a wheel. The index balloons. Mirrors strain. Bandwidth costs skyrocket. And for what? So developers can avoid learning a second tool?

Second: security. When you pip install a Python package, you’re trusting the Python supply chain. When you pip install a compiled binary, you’re trusting… what exactly? The binary inside the wheel wasn’t built by the Python community. It wasn’t vetted by Python’s security tooling. It’s a black box wrapped in a format that looks familiar but isn’t what it claims to be.

The most dangerous security vulnerabilities don’t come from breaking the rules. They come from following the rules of one system to accomplish something that system was never meant to do.

Third: maintenance. Who maintains the Postgres binary inside that wheel? When a CVE drops for PostgreSQL, does the pip package get updated? On whose schedule? With what testing? The Python ecosystem has norms for security patches — but those norms were built for Python code, not for compiled databases shipped as convenience payloads.

None of this is leontrolski’s fault, by the way. The project is a clever, pragmatic response to a real pain point. The developer needed a test database. They found a way to get one with zero friction. They shared it. That’s how open source works — someone scratches an itch, and if the itch is common enough, the solution spreads.

The problem isn’t the project. The problem is what the project reveals: our package management infrastructure was built for a world where ecosystems stayed in their lanes. That world is gone. Developers move fluidly between languages, tools, and platforms. They want one command to rule them all. And they’ll abuse whatever system lets them get there.

We didn’t design package managers to be universal. We just made them too convenient to use for anything else. Now we’re living with the consequences — and calling it innovation.

So should you use pip-installable Postgres? For a throwaway test database? Probably. It’s fast, it’s clean, and the risk profile for a local dev instance is low. But understand what you’re participating in: the slow, quiet transformation of PyPI from a Python package index into a general-purpose software distribution platform — one pip install at a time.

The convenience is real. The trade-off is real. And the person who has to clean up the mess — when PyPI is hosting 50TB of non-Python binaries and nobody knows who’s responsible for security updates — hasn’t been born yet. But they will be. And they’ll be very, very annoyed.