Flexible Deployment: What Enterprise-Grade Self-Hosting Actually Demands

Ask a database vendor about on-prem and you'll usually get a one-line answer: 'we're open source, you can just self-host it.' For a hobby project, fine. For an enterprise, that line rarely survives contact with production. And enterprises want on-prem more than ever right now, largely because of AI. Running open models on hardware you own is far cheaper than renting inference by the token, and in a regulated industry, keeping data where you control it isn't optional. When the models move in-house, the database moves with them, because that's where the data lives and, increasingly, where the AI feeds on it.

So a lot of teams are asking a question they thought they had retired: can we run this in our own environment, on our own terms? Plenty of vendors have a ready answer. “Sure, we are open source. Just self-host.” For a solo developer or a small team, that answer holds up fine. For an enterprise, it usually falls apart, because open source, self-hostable, and enterprise-ready are three different promises, and most vendors only deliver the first.

Three Words, Three Different Promises

When a cloud-native vendor tells you to run their open source on-prem, what they are usually handing you is the exact architecture they operate as a managed cloud service, boxed up for you to run yourself. Open-sourcing is a generous thing to do. It also dumps a pile of undifferentiated work on your team: stand up a distributed system with a lot of moving parts, secure it, wire in backups and high availability, and then keep every component patched, forever. That is not what an enterprise self-hosting team is trying to buy. Two real examples show why.

Self-Hosting Should Be a Product, Not a Cloud in a Box

Enterprise self-hosting should give you a product you can own and run, not the vendor's cloud with the managed parts turned off. Supabase is a good example. It's an excellent product, fully open source, and a pleasure to run for a prototype. Production is where the self-hosted edition struggles.

Self-hosting it means operating about a dozen containers, Postgres, an API gateway, auth, REST, realtime, storage, an image proxy, a pooler, and edge functions, all yours to secure, patch, and recover. And it runs as a single project. Supabase's own self-hosting docs put it plainly (as of August 2026):

Self-hosted Supabase runs as a single project which means that Studio doesn't support multiple organizations or projects. Most settings are configured through environment variables.

Unlike the managed platform, which is fully hosted and operated by Supabase, branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL, and the platform management API are unavailable.

That's because it's the same code they run as a cloud service, with the platform features flagged off and even cloud regions hardcoded.

We ran it. Creating a project errors out, the backups page 404s, and the branching dialog quotes Supabase's cloud rate, $0.01344 an hour for compute, on hardware you already own. A team that forked Supabase to fix this stripped about 350,000 lines of cloud-specific code and called self-hosting "a side quest," not a first-class path.

Self-Hosted Should Mean You Own It

Self-hosted should mean you fully own and operate the system, with nobody else in the loop. Xata gets closer than most, and deserves credit for it: the core is open source, it was built with deployment in mind, and its Bring Your Own Cloud model runs in your own cloud account or on your own hardware, not just a data center you own. Its anonymization tooling, which scrubs sensitive fields before data leaves your account, is a smart feature for regulated teams.

But look at how it runs, from Xata's own deployment docs: "The Xata control plane—responsible for managing organizations, users, regions, and instances—continues to run in our AWS account." So even with your databases on-prem, a vendor-run cloud service reaches in to start, stop, and manage them. For a regulated or security-conscious team, letting an outside cloud app control on-prem infrastructure is often a non-starter, and it rules out running disconnected or air-gapped. Your data is on-prem, but the system that operates it isn't yours.

What Enterprises Are Actually Buying

Step back and the pattern becomes obvious. “Run our open source” hands you a cloud architecture, a lot of replatforming and adaptation work, and a large operations bill. Enterprise self-hosting is a narrower, more specific thing, and it is less about a source code repository and more about a delivery and supply-chain discipline. In practice, the shopping list looks like this:

• Precompiled, tested, validated binaries and packages for the exact CPU architecture and operating system in play, not a build-it-yourself reference stack.

• Delivery in enterprise-native formats that fit existing process and policy: signed OS packages, systemd services, signed container images, and configuration-management automation.

• Verifiable provenance, meaning signed repositories and a signed software bill of materials (SBOM) so security and audit teams can see exactly what was installed and where it came from. SBOMS are now mandatory for products used by US government agencies and contractors, and are also increasingly required by other large enterprises.

• Support for hardened environments, including FIPS-validated cryptography and fully air-gapped installation.

• A lifecycle you can trust: prompt security patching and clear upgrade paths, with no dependency on a vendor cloud that phones home.

This is unglamorous work requiring serious investment.. A build-and-validation matrix, package signing, offline install procedures, and FIPS toolchains do not make for a flashy press release. They are also exactly the parts that “just self-host” skips, and they are the parts pgEdge has spent a good deal of effort working to get it right.

Where pgEdge Does the Hard Part

pgEdge Enterprise Postgres is 100% open-source PostgreSQL, not a fork, delivered the way enterprises actually consume software. Underneath it sits a broad, tested build matrix: two CPU architectures (x86_64 and arm64), Enterprise Linux 9 and 10 (RHEL, AlmaLinux, Rocky, and Oracle Linux), Ubuntu and Debian, and PostgreSQL 16, 17, and 18. Each target carries hundreds of validated packages: Postgres itself, plus the extensions, replication components, and tooling, every one compiled, tested, and validated. Multiply that across the architectures, operating systems, and PostgreSQL versions, and the catalog runs well into the thousands, not a single reference stack you are left to adapt. The details live in the pgEdge Enterprise Postgres documentation.

Those builds ship in the formats real environments run on: RPM and Debian packages, Docker containers, Helm charts, and Ansible automation. The same validated software drops into an OS-package workflow, a container platform, Kubernetes, or a config-managed fleet without anyone repackaging it by hand. Provenance is built in. The RPMs are signed, the Debian repository is signed, and a signed SBOM ships inside the packages, so security and audit teams get a verifiable inventory for free. For regulated and government work, pgEdge supports both FIPS and non-FIPS environments, a bar neither “just self-host” option clears.

Two details matter more than they might seem. First, installation is simply a signed package and a systemd service, rather than the assembly and hardening of a sixteen-container stack. Second, it works completely offline. pgEdge documents an air-gapped installation procedure for both Enterprise Linux and Debian and Ubuntu, so packages and dependencies can be mirrored to a local repository behind an isolation boundary with nothing reaching out. And when the PostgreSQL community ships a minor or security release, pgEdge ships the matching update the same day, across the whole matrix, so there is no patch lag while someone rebuilds a bespoke stack. We also endeavor (but don’t guarantee) to ship major Postgres versions the same day the community releases them.

Run It Yourself, Kubernetes Is Not Mandatory

Delivering the software is half the story. Operating the database is the other half, and it is where the tether in the “self-hosted” offerings shows most clearly. Supabase leaves high availability as a do-it-yourself project, and Xata needs a Kubernetes cluster plus a control plane that lives in the vendor's cloud. pgEdge Control Plane answers both. As described in the launch post and the documentation, it is a declarative, API-driven service for deploying and operating highly available Postgres across a fleet of machines, on bare metal, virtual machines, on-prem, in your cloud, or a mix, with nothing phoning home. If you do want Kubernetes, pgEdge supports that path too, through pgEdge Helm charts and CloudNativePG. The point is that Kubernetes is a choice here, not a prerequisite.

You describe the state you want: which nodes run, how many replicas, where backups go, which roles exist. The Control Plane converges the running system to match. It leans on an embedded, strongly-consistent store and a durable, resumable workflow engine, so operations finish cleanly even if a machine crashes mid-change. High availability comes two ways: alone or together. Patroni provides physical replication with automatic failover. pgEdge Spock provides multi-active logical replication, where every node can accept writes. Scheduled backups, WAL archiving, and point-in-time recovery come through pgBackRest. And all of it runs entirely inside your own environment. It is the convenience of a managed service, without giving up the ownership a managed service can never hand back.

Your Data, Your Models, Your Choice

The same flexibility matters even more for AI, and here too the deployment decision belongs to you, not the vendor. Run the whole stack inside your own environment when sovereignty and cost demand it, or reach out to cloud models when that serves you better. The pgEdge Agentic AI Toolkit supports both. It gives AI agents structured, governed access to your database through a Postgres MCP Server, a RAG Server with hybrid vector-and-keyword search, and Vectorizer and Docloader for building embedding pipelines. A pgEdge Anonymizer covers the same safe-dev-copy need Xata highlights, except here it is part of software you own outright, and the AI DBA Workbench adds AI-assisted database operations.

Then there's pgEdge ColdFront, still in beta. AI and compliance workloads pile up huge amounts of data that you rarely touch again but are required to keep. Storing all of it on your main, fast database disk gets expensive. As the ColdFront announcement explains, it runs on stock upstream PostgreSQL and transparently tiers older data to open Apache Iceberg format on object storage at up to 90% lower storage cost, while keeping that data readable and writable through the same table name. A compliance deletion becomes a single SQL statement instead of a restore-and-rearchive project. Put the toolkit and ColdFront together and you get something Supabase and Xata cannot offer: AI that runs on your terms, with your own data, your own RAG, and your own agent access, kept entirely inside your walls when you need it and extended to the cloud when you choose. Alternatively you can rapidly prototype in the cloud, then choose to deploy on-premises as you prepare to go to production.

How They Actually Stack Up

All three are capable pieces of software. The difference is that only pgEdge was built from the start to be bought, secured, and operated by an enterprise on its own terms, in the cloud or self-hosted on-premises, and it shows the moment you line the requirements up side by side.

Supabase and Xata entries reflect their own current documentation and code, linked in Sources. ColdFront is in beta. The pgEdge same-day patch cadence is our own release practice.

Own, Maintain and Operate, versus “Just Self-Host”

Open-sourcing your cloud is a real gift to the community, and both Supabase and Xata have earned their reputations. But an enterprise asking for on-prem is not asking for a copy of somebody's cloud plus a major replatforming exercise and large operations bill. It is asking for validated, signed software built for its exact platforms, delivered the way its process and policy require, operable on its own hardware with no tether home, and hardened for the environments it actually runs, FIPS and air-gapped enclaves included. That is a delivery discipline, not a repository. It is the difference between “you can technically run this” and “you can own, secure, and operate this.” As AI pushes more workloads, and more sensitive data, back inside the enterprise boundary, that difference is what separates the platforms that support production apps from those that only support prototyping and low-risk production use.

Sources

1. Supabase, self-hosting overview https://supabase.com/docs/guides/self-hosting

2. Supabase, self-hosting with Docker (services and securing secrets) https://supabase.com/docs/guides/self-hosting/docker

3. Supabase, Docker README (default configuration is not secure for production use) https://github.com/supabase/supabase/blob/master/docker/README.md

4. Supabase, hardcoded cloud providers and regions (regions.ts) https://github.com/supabase/supabase/blob/master/packages/shared-data/regions.ts

5. Vela, “We Forked Supabase Because Self-Hosted Postgres Is Broken” https://vela.simplyblock.io/blog/vela-open-source/

6. Xata, deployment models (BYOC, Kubernetes, control plane in Xata's cloud) https://xata.io/docs/core-concepts/deployment

7. pgEdge Enterprise Postgres documentation (OS/arch matrix, install) https://docs.pgedge.com/enterprise/

8. pgEdge, offline repository for Enterprise Linux https://docs.pgedge.com/enterprise/el/offline/

9. pgEdge, offline repository for Debian and Ubuntu https://docs.pgedge.com/enterprise/debian/offline/

10. pgEdge Control Plane, launch post https://www.pgedge.com/blog/introducing-the-pgedge-control-plane-high-availability-postgres-simplified

11. pgEdge Control Plane, documentation https://docs.pgedge.com/control-plane/

12. pgEdge ColdFront, announcement https://www.pgedge.com/blog/introducing-coldfront-seamlessly-uniting-oltp-analytics-and-ai-workloads-on-postgresql

13. pgEdge Agentic AI Toolkit, documentation https://docs.pgedge.com/ai-toolkit/