more ee stuff

Author: levkk

docs/enterprise_edition/control_plane/self-hosting.md

@@ -34,7 +34,7 @@ The following values should be set in `values.yaml`:
 |-|-|
 | `image.tag` | The Docker tag for the control plane image. |
 | `ingress.host` | The DNS host for the control plane, e.g., `pgdog.database.internal`. |
-| `env` | A key/value mapping of [environment varialbes](#configuration) passed to the control plane application. |
+| `env` | A key/value mapping of [environment variables](#configuration) passed to the control plane application. |
 
 For example:
 
@@ -44,26 +44,26 @@ image:
 ingress:
   host: pgdog.database.internal
 env:
-  SESSION_KEY: 1b80a3cc1640a3[...]
+  DATABASE_URL: postgres://user:password@[...]
 ```
 
 ### Configuration
 
 The control plane is configured via environment variables. The following variables are required for it to work correctly:
 
-| Environment variable | Description |
-|-|-|
-| `DATABASE_URL` | URL pointing to the Postgres database used for storing control plane data. |
-| `SESSION_KEY` | Secret key used to encrypt user session cookies. Can be any value, as long as it's at least 64 bytes. |
-| `REDIS_URL` | URL pointing to the Redis database used for synchronization. |
-| `FRONTEND_URL` | The URL where the frontend application is hosted. This defaults to `ingress.host` if you're using the Helm chart. |
+| Environment variable | Description | Example |
+|-|-|-|
+| `DATABASE_URL` | URL pointing to the Postgres database used for storing control plane data. | `postgres://user:password@host:5432/db` |
+| `SESSION_KEY` | Secret key used to encrypt user session cookies. Can be any value, as long as it's at least 64 bytes. | `abcsf32a[...]` |
+| `REDIS_URL` | URL pointing to the Redis database used for synchronization. | `redis://127.0.0.1/0` |
+| `FRONTEND_URL` | The URL where the frontend application is hosted. This defaults to `ingress.host` if you're using the Helm chart. | `http://pgdog.internal` |
 
 !!! note "Helm chart"
-    If you're using the [Helm chart](#kubernetes), these are generated from settings in `values.yaml` and don't need to be configured manually.
+    If you're using the [Helm chart](#kubernetes), all variables except `DATABASE_URL` are generated from settings in `values.yaml` and don't need to be configured manually.
 
 #### Session key
 
-The control plane requires a 64 bytes randomly generated session key to encrypt user session cookies. You can generate one with just one line of Python:
+The control plane requires a 64 bytes randomly generated session key to encrypt user session cookies. If you're not using our Helm chart, you can generate one with just one line of Python:
 
 === "Command"
     ```bash
@@ -76,14 +76,14 @@ The control plane requires a 64 bytes randomly generated session key to encrypt
 
 ### Authentication
 
-The control plane web UI suppors two authentication methods:
+The control plane web UI supports two authentication methods:
 
 1. Email and password
 2. OAuth2
 
 Password authentication works out of the box and requires no additional setup beyond creating users via the [CLI](cli.md).
 
-For OAuth2, you need to configure each provider, and depending on which provider you choose, different environment variables need to be set as well:
+For OAuth2, you need to configure each provider, and depending on which provider you choose, different environment variables need to be set:
 
 === "Google"
     | Environment variable | Description |
@@ -98,3 +98,10 @@ For OAuth2, you need to configure each provider, and depending on which provider
     | `GITHUB_CLIENT_ID` | GitHub OAuth2 client identifier. You can obtain one by creating an OAuth application in the [Developer Settings](https://github.com/settings/developers) in your GitHub account. |
     | `GITHUB_CLIENT_SECRET` | GitHub OAuth2 client secret. |
     | `GITHUB_REDIRECT_URL` | OAuth redirect URL. It should be set to the following: `${FRONTEND_URL}/github/oauth/callback`. |
+
+!!! note "OAuth2 redirect"
+     The redirect URL (e.g., `GOOGLE_REDIRECT_URL`) is set automatically by the Helm chart. You only need to set it if you're self-hosting using a different orchestration mechanism.
+
+#### Creating users
+
+You can create a user using the [CLI](cli.md) [`onboard`](cli.md#onboarding) command. It works for both password-based and OAuth2 authentication mechanisms.

docs/enterprise_edition/cross-shard-writes.md

@@ -0,0 +1,31 @@
+---
+icon: material/database-edit
+---
+
+# Cross-shard writes
+
+!!! note "On the roadmap"
+    This feature is still on the [roadmap](index.md#roadmap) and
+    hasn't been built yet.
+
+Queries that create or update rows on multiple shards should be using [two-phase](../features/sharding/2pc.md) transactions. This ensures that table changes are atomic in all databases. The open source edition of PgDog supports this feature out of the box.
+
+The Enterprise edition provides crash protection, in case PgDog itself is restarted or the hardware its running on fails, while in between phase one and phase two of the exchange. This guarantees all two-phase transactions are either committed or rolled back.
+
+## How it works
+
+Two-phase transactions are durable database objects. Once prepared, a 2pc transaction needs to be either committed or rolled back. If this doesn't happen, PostgreSQL won't be able to vacuum affected tables. If left unattended for a long period of time, this will cause a database shutdown.
+
+### Durable two-phase
+
+PgDog Enterprise nodes register each two-phase transaction with the [control plane](control_plane/index.md). When a PgDog process boots up, it will fetch all of its abandoned transactions from the control plane storage, and proceed to clean them up before serving query traffic.
+
+<center>
+    <img src="/images/ee/2pc_storage.png" width="70%" alt="Reload schema">
+</center>
+
+The transaction identifiers and their state are saved in a separate PostgreSQL database. This provides a safety guarantee against control plane crashes as well.
+
+## Status
+
+This feature isn't built yet. We're planning on shipping it in Q2 2026.

docs/enterprise_edition/index.md

@@ -6,13 +6,14 @@ icon: material/office-building
 
 PgDog Enterprise is a version of PgDog that contains additional features for large-scale monitoring and deployment of sharded (and unsharded) PostgreSQL databases.
 
-Unlike PgDog itself, PgDog Enterprise is closed source and available upon the purchase of a license. It comes with a control plane which provides real-time visibility into PgDog's operations and enterprise features.
+Unlike PgDog itself, PgDog Enterprise is closed source and available upon the purchase of a license. It comes with a control plane which provides real-time visibility into PgDog's operations and enterprise features and dedicated support from the team that built PgDog.
 
 ## Features
 
 | Feature | Description |
 |-|-|
 | [Control plane](control_plane/index.md) | Synchronize and monitor multiple PgDog processes. |
+| [Schema management](schema.md) | Synchronize database schema changes between multiple PgDog nodes. |
 | [Active queries](insights/active_queries.md) | Real-time view into queries running through PgDog. |
 | [Query plans](insights/query_plans.md) | Root cause slow queries and execution anomalies with real-time Postgres query plans, collected in the background. |
 | [Real-time metrics](metrics.md) | All PgDog metrics, delivered with second-precision through a dedicated connection. |
@@ -40,6 +41,42 @@ The demo comes with the control plane, the web UI and PgDog configured as follow
 
 For questions about the demo, PgDog Enterprise features, or pricing, [contact us](https://calendly.com/lev-pgdog/30min). PgDog can be deployed on-prem, in your cloud account, or entirely managed by us.
 
+## Getting PgDog Enterprise
+
+The Enterprise edition is available from two sources:
+
+1. Our Docker repository
+2. From source
+
+### Docker repository
+
+!!! note "Enterprise license"
+    Before deploying these images to production, make sure you purchased our Enterprise Edition license. You're welcome to use these for evaluation purposes, e.g., demo deployment or in a staging environment.
+
+Both PgDog and the control plane are available as Docker images:
+
+| Application | Repository |
+|-|-|
+| PgDog | `ghcr.io/pgdogdev/pgdog-enterprise` |
+| Control plane | `ghcr.io/pgdogdev/pgdog-enterprise/control` |
+
+If you're using our [Helm chart](../installation.md#kubernetes), you just need to change the `image.repository` and `image.tag` variables, for example:
+
+```yaml
+image:
+  repository: ghcr.io/pgdogdev/pgdog-enterprise
+  tag: 87a6bcae
+```
+
+For deploying the [control plane](control_plane/index.md), you have two options:
+
+1. Use our managed deployment ([contact us](https://calendly.com/lev-pgdog/30min))
+2. [Self-hosting](control_plane/self-hosting.md)
+
+### From source
+
+If you want to manage all aspects of deploying PgDog Enterprise, [get in touch](https://calendly.com/lev-pgdog/30min) and we'll provide you access to the source code via a GitHub deployment key. You'll receive updates at the same frequency as the Docker repository.
+
 ## Roadmap
 
 PgDog Enterprise is new and in active development. A lot of the features we want aren't built yet:
@@ -49,3 +86,4 @@ PgDog Enterprise is new and in active development. A lot of the features we want
 | QoS | Quality of service guarantees, incl. throttling on a per-user/database/query level. |
 | AWS RDS integration | Deploy PgDog on top of AWS RDS, without the hassle of Kubernetes or manual configuration. |
 | Automatic resharding | Detect hot shards and re-shard data without operator intervention. |
+| [Durable two-phase](cross-shard-writes.md) | Rollback / commit abandoned two-phase transactions. |

docs/enterprise_edition/schema.md

@@ -0,0 +1,30 @@
+---
+icon: material/database-sync
+---
+
+# Schema management
+
+PgDog inspects the database schema in order to automatically detect sharded and [omnisharded](../features/sharding/omnishards.md) tables. When new tables are added or existing tables are changed, PgDog's snapshot of the schema needs to be refreshed.
+
+The open source edition supports refreshing the schema for single-node deployments only. The Enterprise edition takes care of synchronizing schema updates across multiple PgDog nodes, ensuring consistent configuration.
+
+## How it works
+
+When a client executes a DDL command, e.g. `CREATE TABLE`, PgDog will send a notification to the [control plane](control_plane/index.md). The control plane will then trigger a schema reload across all registered PgDog nodes.
+
+<center>
+    <img src="/images/ee/reload_schema.png" width="70%" alt="Reload schema">
+</center>
+
+This process takes place in the background, so the schema snapshot across nodes is eventually consistent. This is sufficient for most applications, since migrations run as a separate process and application traffic doesn't use new tables for a considerable amount of time after the schema is changed. This gives PgDog ample time to refresh its schema snapshot.
+
+### Configuration
+
+Schema reloading on DDL is enabled by default. This is configurable in [`pgdog.toml`](../configuration/pgdog.toml/general.md#reload_schema_on_ddl):
+
+```toml
+[general]
+reload_schema_on_ddl = true
+```
+
+In the open source edition, this reloads the schema on the same node only, while in the Enterprise edition, this triggers a schema reload on all PgDog nodes part of the same deployment.