Query Your Production Database in Plain English with Clanker Cloud

Someone asks you, "How many active users signed up this week?" In practice, answering it means: finding the right credentials, opening psql or DataGrip, writing the SQL, and interpreting the result. For a senior engineer with the muscle memory, that might take three minutes. For a PM or an on-call engineer who doesn't live in the database every day, it can take much longer — or not happen at all.

Clanker Cloud removes that gap. You ask the question in plain English. It queries your live database and returns the answer.

---

The production database question problem

The friction between "I have a question" and "I have an answer from the database" is rarely about the question itself. It is almost always about access and syntax.

Access means having the right credentials in the right format, for the right host and port, in a client that can reach the database from your current network. That alone can block someone for 20 minutes on a bad day.

Syntax means knowing — or correctly remembering — the SQL for what you actually want. "What are the slowest queries from the last hour?" is a meaningful operational question. Writing the correct pg_stat_activity or pg_stat_statements query to answer it accurately is a different skill.

These two problems compound. Engineers who live in the database have shortcuts for both. Product managers, founders, and on-call responders strong in application code but not in SQL hit both walls at once.

Clanker Cloud is a local-first AI workspace for infrastructure that connects to your managed databases — AWS RDS (PostgreSQL, MySQL, Aurora), GCP Cloud SQL, DigitalOcean Managed Databases, and Azure Database — and lets you query them in plain English. The translation from natural language to database query happens locally. The results come back as a plain English answer.

---

What natural language database queries actually do

When you type "what are the 10 largest tables in my production database by size?" into Clanker Cloud, several things happen:

1. The natural language question is parsed and translated into the appropriate SQL or metadata query for your database engine.
2. Clanker Cloud connects to the database using credentials stored locally on your machine — in the OS keychain, the same model used by psql connection strings.
3. The query runs against the live database.
4. The results are interpreted and returned as a plain English answer, including the relevant numbers and context.

None of your query results or database contents transit through Clanker Cloud servers. The app is local-first by design, which matters when the database in question is a production database with real user data.

For teams using BYOK models — Gemma 4 via Ollama, Claude Code, Codex, or Hermes — inference can stay fully local as well.

---

Operational monitoring queries

The most common production database questions are operational: is the database healthy, is something slow, is maintenance running?

These are also the questions that require the most specialized SQL knowledge to answer correctly, because they pull from internal database system tables and statistics views that most engineers don't have memorized.

With Clanker Cloud, you can ask them directly:

Connection pool health:

"What is the current connection count on my RDS instance?"

A connection count approaching the max_connections limit is a common prelude to application errors. Clanker Cloud queries pg_stat_activity and returns the current count alongside your configured maximum, so you can see at a glance whether you have headroom.

Performance triage:

"Show me the slowest queries from the last hour."

This pulls from pg_stat_statements and surfaces the queries with the highest mean execution time and the highest total time. Useful during an incident to quickly identify whether a specific query is causing application slowdown.

Maintenance health:

"Is autovacuum running on my PostgreSQL tables?"

Autovacuum keeps PostgreSQL tables clean of dead tuples. When it falls behind, bloat builds and query performance degrades. Clanker Cloud surfaces which tables autovacuum has run on recently and which ones may be lagging.

Replication health:

"What is the current replication lag on my read replica?"

For applications that route reads to a replica, replication lag directly affects data freshness. Clanker Cloud queries replication statistics and returns lag in seconds — useful during deploys or when investigating stale reads.

These are the kinds of questions that, in a traditional setup, require either memorized SQL or a lookup. With a live database query AI in the loop, the question becomes the query.

---

Data exploration without writing SQL

A different class of questions comes from people who aren't running incidents — they want to know something about the business, and the answer lives in the database.

Product managers, founders, and account managers regularly need numbers that only exist in production:

• "How many active users signed up in the last 7 days?"
• "What is the row count of the orders table?"
• "How many orders were placed this week?"

These are not complex queries. But answering them still requires someone with database access to write and run the SQL. That creates a bottleneck: the question sits until an engineer has time, or the answer never gets looked up at all.

Clanker Cloud makes these queries self-service. The person with the question asks it directly. They get back a number, not a ticket in a queue. Engineers stop being ad-hoc reporting tools.

This also matters for data not yet modeled into a warehouse dashboard — new tables, recent schema additions, operational counts that aren't worth building a report for.

---

Schema and structure discovery

The live database schema is always authoritative. Documentation can go stale. ERDs in Confluence drift. The migrations someone wrote two sprints ago may or may not have been run in production.

Querying the live database directly is the only reliable approach. Clanker Cloud makes that conversational:

• "What indexes exist on the users table?"
• "Show me all tables that don't have an index on created_at."
• "What foreign keys reference the products table?"

The first is useful during onboarding: a new engineer gets an accurate picture of table indexing without needing to know the pg_indexes view. The second surfaces index gaps — useful when reviewing query performance across a set of tables. The third matters before writing a migration that touches a heavily referenced table. Each answer comes from the live schema, not documentation that may be months out of date.

---

Performance optimization queries

Performance optimization in PostgreSQL specifically often requires queries that most engineers need to look up every time: pg_stat_statements for query-level statistics, TOAST and dead tuple counts for table bloat, index scan ratios for index utilization.

These are not obscure queries, but they are not intuitive either. The SQL is verbose, the system tables are specific to PostgreSQL, and the thresholds that indicate a problem are not always obvious from the raw numbers.

Clanker Cloud handles the SQL and the interpretation:

Table bloat:

"Are there any tables with bloat over 30%?"

Dead tuples accumulate as rows are updated and deleted without being vacuumed. Significant bloat means more disk usage, slower sequential scans, and degraded index effectiveness. Clanker Cloud queries the relevant stats and flags tables above a meaningful threshold.

CPU-heavy queries:

"Which queries are consuming the most CPU time according to pg_stat_statements?"

CPU time in pg_stat_statements is a strong signal for optimization candidates. Clanker Cloud surfaces the top offenders sorted by total CPU time — often more actionable than mean time alone.

Latency profiling:

"What is the average query latency for my top 5 most frequent queries?"

Frequency and latency together tell you where to focus. A query running 10,000 times per minute at 5ms has different optimization implications than one running 100 times per minute at 500ms. Clanker Cloud combines both dimensions into a readable answer.

---

The AI coding agent use case

This is where natural language database queries become something more than a convenience tool.

When a developer is working in Claude Code or Codex on a feature that reads from or writes to the database, the generated code is only as good as the schema information the agent has access to. If it's working from a schema file that's three weeks old, it will write queries against column names that no longer exist or miss columns that were recently added.

Clanker Cloud exposes an MCP endpoint. Claude Code and Codex can connect to it during a coding session and query the live database directly.

While generating a migration for the orders table, Claude Code asks Clanker Cloud MCP:

"What is the current schema of the orders table in the production PostgreSQL database?"

Clanker Cloud queries production and returns the actual column names, types, constraints, and indexes. Claude Code generates a migration that matches reality, not a stale schema file.

The same applies to Codex: rather than inferring column names from variable names in the codebase, the agent can verify them against the live schema before writing SQL.

See how Clanker Cloud works with AI agents for the full MCP integration details.

---

Security and data safety

Connecting any AI tool to a production database is a reasonable thing to be cautious about. The security model for Clanker Cloud is specific and worth understanding.

Read-only by default. All natural language database queries through Clanker Cloud are read-only unless you explicitly enable maker mode. No INSERT, UPDATE, DELETE, or DDL executes without intentionally switching modes and approving the specific operation.

Schema changes require explicit approval. Even in maker mode, ALTER TABLE, DROP COLUMN, and CREATE INDEX operations require an explicit review step. Clanker Cloud presents the generated SQL before execution.

Credentials stay on your machine. Database credentials are stored in the OS keychain of your local Clanker Cloud installation — not uploaded to any server, not included in API requests. Connections go directly from your machine to the database.

Query results stay local. The result set is processed on your machine. Your database contents — user data, business data, any row returned by a query — do not transit through Clanker Cloud infrastructure. That is a meaningful distinction from web-based database tools that proxy queries through their own servers.

BYOK inference. For teams using Gemma 4 via Ollama, inference runs entirely on the local machine — the natural language question and query results never reach an external model API. For Claude Code and Codex integrations, schema queries via MCP use schema metadata only, not row data, unless you explicitly construct a query that returns it.

The security posture is: same access model as psql, same credential storage as a local database client, read-only by default, nothing leaves the machine unless you configure it to.

For teams with compliance requirements around production data access, Clanker Cloud Enterprise offers custom configuration. See the FAQ for more on data handling.

---

Frequently asked questions

Can I query my production database with Clanker Cloud?

Yes. Clanker Cloud connects to AWS RDS (PostgreSQL, MySQL, Aurora), GCP Cloud SQL, DigitalOcean Managed Databases, and Azure Database. You configure the connection in the local app using a standard connection string or individual host/port/credential fields. Once connected, you can query the database in plain English.

Is it safe to connect a production database to an AI tool?

The relevant safety properties are: credentials stored locally in the OS keychain, connections made directly from your machine, query results processed locally and not sent to Clanker Cloud servers, and a read-only default mode that prevents writes without explicit configuration. The model is closer to connecting a local database client like psql or DataGrip than to routing queries through a third-party service. Schema changes require maker mode and explicit approval.

How do I check database performance without writing SQL?

Clanker Cloud translates operational questions into the appropriate database queries automatically. Ask "show me the slowest queries from the last hour," "what is the current connection count," or "which tables have the most dead tuples" in plain English. Clanker Cloud handles the pg_stat_statements, pg_stat_activity, and related queries, and returns the results interpreted in plain language.

Can Claude Code or Codex see my live database schema?

Yes, through the Clanker Cloud MCP endpoint. During a coding session, Claude Code or Codex can connect to Clanker Cloud MCP and query the live database schema — table structures, column types, indexes, foreign keys. The generated code reflects the actual current schema rather than assumptions or stale documentation. See the AI agents documentation for setup details.

---

Get started

Natural language database queries are available across all Clanker Cloud plans. Beta access is free. Lite is $5/month. Pro is $20/month. Enterprise pricing is available for teams with custom compliance or deployment requirements.

Connect your first database or read the full documentation at docs.clankercloud.ai to see connection configuration, MCP setup, and maker mode details.

If you want to see it working before connecting anything, the interactive demo shows a live query session against a sample production-equivalent database.