pgAgroal Enterprise · Explanation

Open-core boundary

pgAgroal Enterprise is an open-core product. The pooler and its container are free and open; the operation, fleet, and compliance layer above them is licensed. This page draws that line precisely so you know what you get for free and what you pay for.

Short version: the data path is free, forever. You pay for operating many poolers at fleet scale, for maintenance guarantees, and for compliance tooling — never for a feature that moves bytes between your application and PostgreSQL.

Two products, one base

There are two products, and the paid one is built directly on top of the free one:

Elevarq pgAgroal (free) — standard upstream pgagroal, cleanly packaged as a container. Open, BSD-3-Clause, source-available, distributed at no cost on Docker Hub, GHCR, and the cloud marketplaces. See the pgAgroal Container docs.
Elevarq pgAgroal Enterprise (paid) — a closed, proprietary layer that runs alongside standard pgagroal, using it directly as its base.

The base stays open and standard. There is no private runtime fork of pgagroal core hidden inside the container — Enterprise tracks upstream and layers closed functionality above it, rather than maintaining a divergent fork.

What is free vs what is licensed

The boundary is about operation and assurance, not about the pooler itself. pgagroal is already fast; speed is not the price tag. The paid product sells the operation of pgagroal at scale.

Free and open (pgAgroal Container)	Licensed (pgAgroal Enterprise)
Connection pooling: session, transaction, and performance pipelines	Central control plane for many pgagroal deployments
Security and correctness fixes, parser/protocol hardening	Fleet config, policy enforcement, drift detection
Transaction-pooling correctness, reset-query, TLS correctness	Kubernetes operator and rolling-drain automation
Prepared-statement compatibility, pgBouncer compatibility	Managed upgrades and rollback
Basic metrics	HA / failover orchestration as a control layer
The container image, free on every registry and marketplace	Signed images, SBOMs, provenance, CVE-response guarantees
Anything needed to keep pgagroal safe, correct, and broadly usable	Advanced audit streams and compliance exports, cloud IAM integrations
	Enterprise support and SLAs; marketplace procurement on existing cloud spend

Advanced read routing, workload classes, global limits, and circuit breakers are Enterprise only when implemented as part of the control layer — the generic pooler behaviour beneath them stays upstream-first (see the rule below).

The commitments behind the line

The boundary rests on two promises that do not change with commercial priority:

Never block or delay upstream

Security and correctness fixes, parser and protocol hardening, generic pooler behaviour, and anything the community needs go upstream first, on the community's timeline. If a commercial priority and an upstream need ever conflict, upstream wins. Functionality flows from closed to open over time where generally useful — never the reverse. A capability is never pulled out of upstream to monetise it.

Never paywall the data path

Nothing on the path that moves bytes between your application and PostgreSQL is paywalled. The free pooler stays genuinely useful, not artificially crippled to push an upgrade. A faster, more capable free pgagroal makes the paid product more valuable, because there is more engine to operate well.

The rule: where does a feature go?

When deciding whether a feature is upstream or Enterprise, the default is upstream. Use this test:

Is it a security fix, a correctness fix, or generic pooler behaviour that keeps pgagroal safe and broadly usable? Upstream-first, always. It is never closed-only.
Does it operate, coordinate, manage, or assure many pgagroal instances — policy, drift, lifecycle, HA orchestration, audit, managed maintenance? Enterprise layer.
When in doubt, it goes upstream. The boundary errs toward open.

Enterprise features may start closed, but they must remain technically separable and upstreamable where reasonable. If a closed feature later becomes a standard pgagroal feature, the paid product keeps adding value through automation, policy, fleet operation, packaging, and managed experience — not by withholding the capability.

In the issue tracker the line is visible through labels, so every change is traceable to the side of the boundary it lands on:

track:upstream   lands in pgagroal (open)
track:closed     Elevarq closed Enterprise product
track:security   coordinated-disclosure work
track:community  optional separate community project (not core, not Enterprise)

Any proprietary feature boundary is documented clearly for customers, so there is no drift between what the docs say is free and what actually is. The arrangement is designed for auditability and supports our compliance readiness.

Why this holds up

The open project loses nothing by Elevarq having a paid product, and gains contributions — including credited CVE work and visible upstream fixes — it would not otherwise get. The closed product is a focused layer above a single pooler: coordination, management, and resilience-at-scale, not the core roadmap withheld behind a paywall. Customers get a clear reason to pay, users keep a strong free base, and upstream has nothing to fear.

See also: Enterprise architecture for how the control plane attaches alongside the pooler, How to buy for procurement of the licensed layer, the pgAgroal Container for the free base, or the upstream pgagroal manual for the pooler itself.