Pricing that scales with your fleet

Ten engines: PostgreSQL, MySQL, MariaDB, MongoDB, SQL Server, Redis, Cassandra, Elasticsearch, Oracle, and Db2. The adapter layer is built to add engines without touching the rest of the platform.

The platform distinguishes local MongoDB, an Atlas cluster (mongodb+srv, TLS, no port), and Atlas shard hosts automatically, and applies the same rules to backups and restores. Because MongoDB is NoSQL, it has a dedicated query runner (mongosh-style shell + a structured find/aggregate builder) instead of SQL. For secured Atlas deployments, Governance → Network Access manages each connection’s Atlas IP allow-list from the tool — connect the Atlas project once (API key stored encrypted), then view, add, and remove access rules and one-click allow-list the platform’s egress IP.

Yes. A query console runs SQL, CQL, and Elasticsearch SQL (read-only by default, every run audited), MongoDB gets its own runner, and on PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, and IBM Db2 an Explain action analyzes a statement’s execution plan — without running it — returning the cost/row plan tree plus optimization hints (missing indexes, full scans, expensive sorts). Explain reaches the NoSQL engines too: MongoDB via `.explain("queryPlanner")` (collection scans, non-index sorts) and Elasticsearch SQL via `_sql/translate` (the native query DSL, full-scan/scripted-query flags). The Schema Explorer browses the complete object hierarchy of any database — tables, views, collections, indexes, procedures, functions, and sequences.

AI analysis is optional and bring-your-own-provider. An admin configures a provider in Settings → AI — Anthropic (Claude), OpenAI, Google (Gemini), xAI (Grok), or any OpenAI-compatible endpoint (Custom) — where the API key is stored AES-256-GCM encrypted and never shown again, and the available models are auto-discovered from the key. When you click "Analyse with AI" — in the Query Console or from a long-running query in the Query Monitor — only the SQL statement and, where supported, its EXPLAIN plan are sent to your chosen provider (never result rows), the answer streams back token-by-token, and every analysis is written to the audit log. If no provider is configured, the feature is simply unavailable.

Yes. The platform is designed to run inside your own infrastructure, storage and backups support on-prem targets, and an mTLS on-prem agent brokers operations to databases that never leave your network.

Connection credentials are encrypted with AES-256-GCM at rest, never returned in API responses, and never written to logs. A KeyProvider abstraction supports Vault, AWS Secrets Manager, and Azure Key Vault.

Every privileged action writes to an append-only audit log enforced at the database level — filterable, exportable to CSV, and mappable to SOC 2 and ISO 27001 controls.

Data-driven RBAC with seven built-in roles plus custom roles across two tiers (organization and workspace). Permissions are enforced at the API, and members can be confined to specific workspaces — even for direct by-id access.

For the platform itself: OpenTelemetry traces, a Prometheus /metrics endpoint, and trace-correlated logs. For your databases: real engine-native telemetry — long-running query detection, live sessions, and native server logs pulled via each engine's client API (PostgreSQL, MySQL, MongoDB, SQL Server, Oracle, Redis, Cassandra, Db2) or an SSH file source for file-only logs — never just application-level events.

Yes. The Replication & HA view draws a visual topology graph — each primary as a node with connector lines to its replicas, colored by health and labelled with per-member lag — mapping primary/replica roles across the fleet, with every cluster member read from the engine itself (PostgreSQL pg_stat_replication, MongoDB rs.status(), Redis INFO replication, MySQL/MariaDB SHOW REPLICAS, SQL Server Always On availability groups, Oracle Data Guard). An HA-health badge flags each cluster as healthy, degraded (a member down or lagging), or single-node with no failover target.