Skip to content

Enterprise edition changelog #1497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
levkk merged 4 commits into from
Sep 3, 2026
+45 −25
Merged

Enterprise edition changelog #1497

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2767d5c
Enterprise edition changelog
levkk Sep 3, 2026
3900ed6
not so big
levkk Sep 3, 2026
f80605a
smaller
levkk Sep 3, 2026
5ee577a
license
levkk Sep 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions CHANGELOG-ENTERPRISE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Changelog EE

This file contains the list of changes made to the Enterprise edition of PgDog. Since it's being developed in a private repository, this seemed like
the most optimal way to share those changes.

### v2026-09-03

**OS version**: v0.1.57

| Application | Docker image |
| ------------- | ------------------------------------------------------- |
| PgDog | `ghcr.io/pgdogdev/pgdog-enterprise:v2026-09-03` |
| Control plane | `ghcr.io/pgdogdev/pgdog-enterprise/control:v2026-09-03` |

#### Features

- Added a UI in the control plane to monitor resharding of databases. It tracks the resharding tasks in real-time, with progress reports and ETA.
- Query plans are now sent asynchronously to the control plane, as they are captured by PgDog. This makes them available quicker in the control plane UI, and uses less network bandwidth. Corresponding settings were added to the control plane Helm chart `v0.2.18`.
- Slow query indicator in the control plane is now configurable via the `slow_queries_threshold` [setting](https://github.com/pgdogdev/helm-ee/#state-store) instead of relying on the presence of a query plan.
- Added the ability to trigger alerts on slow queries as detected by `slow_queries_threshold`. Requires the `slow_queries` setting to be [enabled](https://github.com/pgdogdev/helm-ee/#alerting).

#### Bug fixes

- Query blocking command in the admin database now uses correctly normalized SQL; it would previously lowercase the query first, potentially causing mismatching
- PgDog would reload its config when a node would join the cluster, irrespective if connection pool autoscaling was enabled. This would cause connection pools to drop connections due to incompatible configuration changes between the new and old pools. This required the control plane to be enabled.
45 changes: 20 additions & 25 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,16 @@

[![CI](https://github.com/levkk/pgdog/actions/workflows/ci.yml/badge.svg)](https://github.com/levkk/pgdog/actions/workflows/ci.yml)

PgDog is a proxy for scaling PostgreSQL. It supports connection pooling, load balancing queries and sharding entire databases. Written in Rust, PgDog is fast, secure and can manage thousands of connections on commodity hardware.
PgDog is an open source proxy for scaling PostgreSQL. It supports connection pooling, load balancing queries and sharding entire databases. Written in Rust, PgDog is fast, secure and can manage thousands of connections on commodity hardware.

## Documentation

📘 PgDog documentation can be **[found here](https://docs.pgdog.dev/)**. Any questions? Chat with us on **[Discord](https://discord.com/invite/CcBZkjSJdd)**.

##### Enterprise edition

🏢 Enterprise edition (EE) documentation is availble **[here](https://docs.pgdog.dev/enterprise_edition/)**. Changelog is available **[here](CHANGELOG-ENTERPRISE.md)**.

## Quick start

### Kubernetes
Expand Down Expand Up @@ -117,7 +121,6 @@ PgDog also has more advanced connection recovery options, like automatic abandon

PgDog is an application layer (OSI Level 7) load balancer for PostgreSQL. It understands the Postgres protocol, can proxy multiple replicas (and primary) and distributes transactions evenly between databases. The load balancer supports 3 strategies: round robin, random and least active connections.


**Example**

The load balancer is enabled automatically when a database has more than one host:
Expand All @@ -138,25 +141,20 @@ role = "replica"

📘 **[Healthchecks](https://docs.pgdog.dev/features/load-balancer/healthchecks/)**


PgDog maintains a real-time list of healthy hosts. When a database fails a health check, it's removed from the active rotation and queries are re-routed to other replicas. This works like an HTTP load balancer, except it's for your database.

Health checks maximize database availability and protect against bad network connections, temporary hardware failures or misconfiguration.


#### Single endpoint

📘 **[Single endpoint](https://docs.pgdog.dev/features/load-balancer/#single-endpoint)**


PgDog uses [`pg_raw_parse`](https://github.com/pgdogdev/pg_raw_parse), which includes the PostgreSQL native parser. By parsing queries, PgDog can detect writes (e.g. `INSERT`, `UPDATE`, `CREATE TABLE`, etc.) and send them to the primary, leaving the replicas to serve reads (`SELECT`). This allows applications to connect to the same PgDog deployment for both reads and writes.


##### Transactions

📘 **[Load balancer & transactions](https://docs.pgdog.dev/features/load-balancer/transactions/)**


Transactions can execute multiple statements, so in a primary & replica configuration, PgDog routes them to the primary. Clients can indicate a transaction is read-only, in which case PgDog will send it to a replica:

```sql
Expand All @@ -166,15 +164,12 @@ SELECT * FROM users LIMIT 1;
COMMIT;
```


#### Failover

📘 **[Failover](https://docs.pgdog.dev/features/load-balancer/replication-failover/)**


PgDog monitors Postgres replication state and can automatically redirect writes to a different database if a replica is promoted. This doesn't replace tools like Patroni that actually orchestrate failovers. You can use PgDog alongside Patroni (or AWS RDS or other managed Postgres host), to gracefully failover live traffic.


**Example**

To enable failover, set all database `role` attributes to `auto` and enable replication monitoring (`lsn_check_delay` setting):
Expand Down Expand Up @@ -443,7 +438,6 @@ COMMIT;

📘 **[Direct-to-shard queries](https://docs.pgdog.dev/features/sharding/query-routing/)**


Queries that contain a sharding key are sent to one database only. This is the best case scenario for sharded databases, since the load is uniformly distributed across the cluster.

**Example**:
Expand All @@ -465,16 +459,15 @@ Queries with multiple sharding keys or without one are sent to all databases and

Currently, support for certain SQL features in cross-shard queries is limited. However, the list of supported ones keeps growing:

| Feature | Supported | Notes |
|-|-|-|
| Aggregates | Partial | `count`, `min`, `max`, `stddev`, `variance`, `sum`, `avg` are supported. |
| `ORDER BY` | Partial | Column in `ORDER BY` clause must be present in the result set. |
| `GROUP BY` | Partial | Same as `ORDER BY`, referenced columns must be present in result set. |
| Multi-tuple `INSERT` | Supported | PgDog generates one statement per tuple and executes them automatically. |
| Feature | Supported | Notes |
| --------------------- | --------- | -------------------------------------------------------------------------------------------- |
| Aggregates | Partial | `count`, `min`, `max`, `stddev`, `variance`, `sum`, `avg` are supported. |
| `ORDER BY` | Partial | Column in `ORDER BY` clause must be present in the result set. |
| `GROUP BY` | Partial | Same as `ORDER BY`, referenced columns must be present in result set. |
| Multi-tuple `INSERT` | Supported | PgDog generates one statement per tuple and executes them automatically. |
| Sharding key `UPDATE` | Supported | PgDog generates a `SELECT`, `INSERT` and `DELETE` statements and execute them automatically. |
| Subqueries | No | The same subquery is executed on all shards. |
| CTEs | No | The same CTE is executed on all shards. |

| Subqueries | No | The same subquery is executed on all shards. |
| CTEs | No | The same CTE is executed on all shards. |

#### Using `COPY`

Expand All @@ -490,7 +483,6 @@ COPY orders (id, user_id, amount) FROM STDIN CSV HEADER;

Columns must be specified in the `COPY` statement, so PgDog can infer the sharding key automatically, but are optional in the data file.


#### Consistency (two-phase commit)

📘 **[Two-phase commit](https://docs.pgdog.dev/features/sharding/2pc/)**
Expand Down Expand Up @@ -577,7 +569,7 @@ The re-sharding process is done in 5 steps:
4. While keeping previous command running (it streams row updates in real-time), run `schema-sync --data-sync-complete` to create secondary indexes on the new databases (much faster to do this after data is copied)
5. Cutover traffic to new cluster with `MAINTENANCE ON`, `RELOAD`, `MAINTENANCE OFF` command sequence

Cutover can be done atomically with multiple PgDog containers because `RELOAD` doesn't resume traffic, `MAINTENANCE OFF` does, so the config is the same in all containers before queries are resumed. No complex synchronization tooling like etcd or Zookeeper is required.
Cutover can be done atomically with multiple PgDog containers because `RELOAD` doesn't resume traffic, `MAINTENANCE OFF` does, so the config is the same in all containers before queries are resumed. No complex synchronization tooling like etcd or Zookeeper is required.

### Monitoring

Expand All @@ -591,7 +583,6 @@ We include two examples:
- [Datadog configuration and dashboard](examples/datadog)
- [Graphana + Prometheus configuration and dashboard](examples/grafana_prometheus)


## Running PgDog locally

Install the latest version of the Rust compiler from [rust-lang.org](https://rust-lang.org).
Expand Down Expand Up @@ -692,15 +683,19 @@ PgDog is heavily optimized for performance. We use Rust, [Tokio](https://tokio.r
PgDog is free and open source software, licensed under the AGPL v3. While often misunderstood, this license is very permissive
and allows the following without any additional requirements from you or your organization:

* Internal use
* Private modifications for internal use without sharing any source code
- Internal use
- Private modifications for internal use without sharing any source code

You can freely use PgDog to power your PostgreSQL databases without having to
share any source code, including proprietary work product or any PgDog modifications you make.

AGPL was written specifically for organizations that offer PgDog _as a public service_ (e.g. database cloud providers) and require
those organizations to share any modifications they make to PgDog, including new features and bug fixes.

### Enterprise edition

If your organization doesn't allow AGPL software, PgDog is also available under an [enterprise](https://docs.pgdog.dev/enterprise_edition/) license.

## Contributions

Please read our [Contribution Guidelines](CONTRIBUTING.md).
Loading