Filtering happens inside the pganalyze collector, on your infrastructure, before anything leaves. Query text is normalized, so secret = '123' is stored as secret = $0. By default the collector also redacts Postgres credentials and any log line it cannot classify. Parameter values in query samples are sent unless you set filter_query_sample: normalize, and filter_log_secret: all can be used to redact every potentially sensitive log message; the docs list the maximum-privacy configuration.

PII filtering

pganalyze Production is $149 per month for one Postgres server with 14 days of history. Scale is $399 per month for four billable servers, then $100 per month per additional server, with 35 days of history, auto_explain plans, Query Advisor, VACUUM Advisor, and Log Insights. Enterprise is priced per engagement, billed annually, with 100 days of history and the option to self-host. Every plan includes unlimited users and a 14-day free trial.

Pricing

The pganalyze Index Advisor looks at every query on a table, not one query at a time, and models how Postgres would use each candidate index with planner logic and a constraint programming solver. It weighs the read time an index saves against the write overhead it adds, so it can avoid an index that speeds up one query but slows down the table writes significantly. Recommendations appear within 48 hours and include the reasoning; nothing is created automatically.

Index Advisor

Yes. The pganalyze MCP Server works with Claude Code, Codex, Cursor, and any other MCP client that supports HTTP transport, such as Claude Desktop, AWS DevOps Agent or VS Code. In Claude Code, add it with claude mcp add --transport http pganalyze https://app.pganalyze.com/mcp. It gives the assistant read access to the query statistics, EXPLAIN plans, Index Advisor results, issues, and logs that pganalyze already collected, so it can investigate a slow query without touching your database. It is in public preview on all current plans.

MCP Server

Yes. pganalyze checks run every 30 minutes, near real time for connection and lock issues, or daily, and alert rules route them to email, Slack, or PagerDuty. Slack receives every severity; email and PagerDuty receive critical issues. Acknowledging or resolving an issue in pganalyze syncs to PagerDuty.

Alerts and check-up

Yes, through OpenTelemetry. The pganalyze collector can export a span for each EXPLAIN plan it collects to Honeycomb, Datadog, or New Relic, linked to the application trace through a traceparent query tag, so a slow database span in your APM opens the matching plan in pganalyze.

OpenTelemetry integration

Datadog Database Monitoring fits when you want database metrics inside a general observability platform. pganalyze goes deeper on Postgres: it normalizes and PII-filters EXPLAIN plans, its Index Advisor evaluates every query on a table, and it adds VACUUM tuning, Query Advisor rewrites, Workbooks, and built-in Postgres log parsing. Many teams combine Datadog APM with pganalyze: the pganalyze collector exports each EXPLAIN plan as an OpenTelemetry span into your Datadog APM traces, matched through the traceparent query tag the Datadog tracing library adds with DD_DBM_PROPAGATION_MODE set to full, so a slow database span in Datadog opens the plan in pganalyze.

pganalyze vs Datadog

No. Application performance monitoring tools trace requests across your services. pganalyze is a Postgres performance tool: it profiles the database itself and tells you which index, query change, or autovacuum setting to fix. It complements an APM; the OpenTelemetry integration links a slow database span in Datadog, Honeycomb, or New Relic to its EXPLAIN plan in pganalyze.

OpenTelemetry integration