DBGorilla and CloudNativePG

DBGorilla now supports CloudNativePG, in production, in your pull requests, and in your editor.

We read your cluster continuously, so we know where to look. Then we test every conclusion on a clone of your database, so we know we are right before we tell you.

What we see

The collector reads the cluster the operator runs and the databases inside it.

From the operator layer: replication lag, and the CPU, memory and volume of each database pod. From the databases: table sizes, index usage, the queries that actually run, and how all of that has moved over time.

That is what tells an agent something is worth investigating: a plan that changed, an index nobody uses any more, a table growing toward a problem.

What a clone is, and why it is enough

A clone has three things. Your schema. Your production statistics. Mock data, generated to whatever volume the question needs.

Postgres does not choose a plan by reading your rows. It chooses from the statistics it keeps about them, so a clone carrying your statistics plans the way your production plans. The mock data is there for everything statistics cannot answer. An agent generates as much as it needs to prove or disprove its theory, which is why a question about a lock and a question about a plan do not get the same clone.

What a clone does not have is your row content. That is not a redaction step or a privacy mode. The clone never held it.

How an agent gets from a metric to a recommendation

The metrics give an agent a theory. The experiment is how it finds out whether the theory is right. It builds the clone that theory needs, runs it, reads the result, and only then says something.

So “this index helps” means we created it and measured it. “This migration is safe” means we ran it at the volume it will actually hit and watched the lock.

This is where we part company with tools that hand your schema to a language model. A model with your schema in context produces confident sentences. It has not run anything. That difference stays invisible until the first time it is confidently wrong at your scale.

It is also not a premium tier or a mode you enable. All three surfaces call the same agents and get the same validation.

We run CloudNativePG too

Testing every recommendation means creating and destroying databases all day, with nobody waiting on the loop. That is only practical when a database is something you declare in code.

It is the same reason you run the operator. The clones our agents experiment against are CloudNativePG clusters.

The three surfaces

In production, agents watch the metrics, form a theory about what they show, test it, and open the work only if the test holds.

In the pull request, the CI bot puts a tested consequence next to the diff. A migration against a fifty million row table gets labeled as one, because we ran it against fifty million rows.

In your editor, over MCP, while you are still writing the change.

Where the clone runs

On SaaS we build it in our infrastructure. In a private VPC or on-prem deployment it runs in yours. Running CloudNativePG on your own hardware does not mean you need the on-prem deployment.

Installing it

The collector runs in the same Kubernetes cluster as your databases, installed with the official Helm chart. It reads the Kubernetes API with its own ServiceAccount and scrapes each instance directly, and neither of those works from outside the cluster.

Give it a read-only login with pg_monitor, plus USAGE and SELECT on the schemas you want captured. pg_monitor on its own gets you metrics and no schema, and nothing about the collector looks unhealthy while that is happening.

It needs your databases on 5432, each instance on its metrics port, and otlp.dbgorilla.com and auth.dbgorilla.com on 443. The chart renders no Service and no inbound ports, so nothing has to reach the collector. If your database namespace runs a default-deny policy, the collector still has to be admitted for those outbound connections, including to individual pod addresses. Admitting it to the -rw service alone is the common mistake, and it stops collection entirely rather than partially.

SQL goes to the -rw service and nowhere else. CloudNativePG issues one certificate per Cluster, covering the -rw, -ro and -r names and no pod names or addresses, so a SQL connection to a pod can never verify. There is no CA to mount and no ca_cert to set. Failover is handled for you: the collector asks Kubernetes which pod is the primary, so a promotion changes nothing in your config and loses no history.

What leaves is the shape and behavior described above, plus query text with the literal values already normalized out. Your row content stays in your database.

Our CloudNativePG collector installation guide has the chart values and the grants.

What you get

Your manifests describe what the cluster should be. We describe what it has become.