Running Several Replicas
Enterprise feature
Running several gdotv replicas behind one load balancer is available in gdotv Enterprise, in server deployments (including the AWS, Azure and Google Cloud marketplace offers) on PostgreSQL. gdotv Team and the desktop app run as a single process. If you'd like to discuss upgrading to gdotv Enterprise, contact us at sales@gdotv.com.
For availability and load, a gdotv Enterprise server can run as several identical replicas (for example a Kubernetes Deployment with replicas: 2 or more) behind a load balancer. Any request can reach any replica: browsers, MCP clients and their "Open in gdotv" links need no session affinity.
Turning on cluster mode
With the gdotv Helm chart (including the marketplace offers), setting gdotv.replicaCount above 1 turns cluster mode on (gdotv.cluster.enabled: auto). If you scale another way (kubectl scale, an autoscaler), set gdotv.cluster.enabled=true yourself: the chart cannot see those replica counts.
Elsewhere, set this environment variable on every gdotv replica:
GDOTV_CLUSTER_ENABLED=trueCluster mode moves what a single gdotv process keeps in memory to PostgreSQL, which every replica already shares. gdotv refuses to start in cluster mode unless it is the Enterprise edition, uses a PostgreSQL database and runs as a server deployment; the startup log names what is missing.
Keep a single replica, without the variable, if you do not need more: nothing changes for it.
Database connection
Replicas notify each other through PostgreSQL LISTEN/NOTIFY, on one long-lived connection per replica besides the usual pool. LISTEN needs a direct, session-mode connection: if gdotv reaches PostgreSQL through a pooler in transaction mode (such as PgBouncer), point that one connection at PostgreSQL itself:
GDOTV_CLUSTER_LISTEN_URL=jdbc:postgresql://postgres-primary:5432/gdotvIt uses the same user and password as the main connection. With the Helm chart, set gdotv.cluster.listenUrl.
Load balancer
No sticky sessions are needed. The WebSocket at /ws (live updates in the app) must be forwarded, as in a single-replica deployment.
What is shared between replicas
| What | How |
|---|---|
| Sign-in sessions | Stored in PostgreSQL (as in every server deployment). |
| MCP clients | The MCP server answers without sessions, so an agent's consecutive calls can reach different replicas. The audit trail still names the MCP client. |
| MCP query results and "Open in gdotv" links | Stored in PostgreSQL for their lifetime (minutes), so get_query_result and the link work on any replica. |
| Live updates (activity bell, an agent's edits to a draft, "changed by another user" banners, connections added, changed or deleted) | Every replica relays them to the browsers connected to it. |
| Connection and AI provider changes | A connection edited or deleted on one replica is dropped from every replica's cache; the next query anywhere uses the new settings. |
| Drafts and stored schemas | Edits of the same dashboard or report by one person, through any replicas, end up in one draft. |
Limits
- Embedded file databases. LadybugDB and Kuzu connections open files on the replica's own disk, which the other replicas do not have. Do not use them in a deployment with several replicas.
- Short-lived caches. Each replica caches a connection's last connectivity check (up to 5 minutes), its database role bindings (up to 2 minutes) and its licence status. A role binding changed on one replica can take up to 2 minutes to apply on the others.
- Passwords that are not remembered. A connection set not to remember its password keeps the password you enter in the memory of the replica that received it. When a later request reaches another replica, gdotv may ask for the password again.
- MCP tool lists. MCP clients are not notified when a role change alters the tools they may use; the list they get on their next
tools/listcall is up to date. - Background cleanups (expired MCP results and links, audit retention) run on every replica. They are idempotent.