AI Tools Compared

Database performance bottlenecks are invisible until they become critical. Modern AI coding assistants can analyze query execution plans, suggest index improvements, and refactor slow queries in seconds. This guide shows exactly which AI tools excel at database optimization and how to use them effectively with your PostgreSQL, MySQL, and MongoDB databases.

Why AI Tools Excel at Query Optimization

Database optimization typically requires deep expertise in execution plans, index structures, and query cost analysis. AI tools trained on thousands of optimization patterns can:

The human DBA remains critical—you validate recommendations and understand business context—but AI accelerates the initial diagnosis from hours to minutes.

Tool Comparison for Database Optimization

Tool Best For Query Context Support Reasoning Quality Price
Claude 3.5 Sonnet Complex multi-table refactoring, explaining trade-offs 200K tokens (entire logs) Exceptional—explains cost model $3/MTok input
ChatGPT-4 Quick optimization suggestions, index recommendations 128K tokens Good for standard patterns $0.03/1K input
GitHub Copilot IDE-integrated suggestions, index creation Limited context Handles simple cases $10/month
Perplexity Pro Research recent optimization papers Web-enabled Current techniques $20/month
Local Code Llama Self-hosted, on-premises compliance 8K tokens (full queries) Good for team codebases Free

Recommendation: Use Claude 3.5 Sonnet for critical query analysis (you can paste entire execution plans), ChatGPT-4 for quick suggestions, and Code Llama for internal team patterns.

Step 1: Capture Your Query Execution Plans

The most valuable input to AI tools is your actual execution plan. Here’s how to extract them:

PostgreSQL

-- Get detailed execution plan with actual rows
EXPLAIN (ANALYZE, BUFFERS, VERBOSE, COSTS)
SELECT o.order_id, c.customer_name, SUM(oi.quantity)
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
GROUP BY o.order_id, c.customer_name;

-- JSON format for AI analysis (easier to parse)
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) [QUERY];

MySQL

-- Get query cost estimate
EXPLAIN FORMAT=JSON
SELECT o.order_id, c.customer_name, SUM(oi.quantity)
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.created_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
GROUP BY o.order_id, c.customer_name;

-- Show index cardinality
ANALYZE TABLE orders;
SELECT * FROM information_schema.STATISTICS WHERE TABLE_NAME='orders';

MongoDB

// Get execution plan with stage breakdown
db.orders.aggregate([
  { $match: { created_at: { $gte: new Date(Date.now() - 30*24*60*60*1000) } } },
  { $lookup: { from: "customers", localField: "customer_id", foreignField: "_id", as: "customer" } },
  { $group: { _id: "$order_id", total: { $sum: "$quantity" } } }
]).explain("executionStats")

Step 2: Analyze with Claude 3.5 Sonnet

Paste your execution plan directly into Claude with context:

Here's my PostgreSQL query that's running in 15 seconds.
The table has 50M orders, 100K customers, and 500M order_items.

[Paste full EXPLAIN output here]

What's the bottleneck and how can I optimize this?
Show me the exact SQL and indexes to create.

Claude will identify issues like:

Example response pattern:

The bottleneck is the sequential scan on order_items. Your planner
chose a hash join when a nested loop with an index scan would be faster.

Create these indexes:
1. CREATE INDEX idx_orders_created ON orders(created_at, customer_id)
2. CREATE INDEX idx_orderitems_order ON order_items(order_id)

Then refactor your query to filter earlier:

SELECT o.order_id, c.customer_name, SUM(oi.quantity)
FROM orders o
WHERE o.created_at > NOW() - INTERVAL '30 days'
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
GROUP BY o.order_id, c.customer_name;

This pushes the date filter down before joins, reducing rows processed.

Step 3: Index Recommendations with Analysis

Claude and ChatGPT can analyze your existing indexes and recommend improvements:

-- Show current indexes
SELECT schemaname, tablename, indexname, indexdef
FROM pg_indexes
WHERE tablename IN ('orders', 'customers', 'order_items');

-- Show which indexes are actually used
SELECT schemaname, tablename, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
ORDER BY idx_scan DESC;

Paste this to Claude with the question:

“Which of these indexes are unused and safe to drop? What new indexes would improve my common queries?”

Step 4: Automate Detection with Monitoring

Use AI to generate monitoring queries that flag slow queries automatically:

PostgreSQL Slow Query Detection

-- View that shows queries exceeding 1 second
CREATE VIEW slow_queries AS
SELECT query, calls, total_time, mean_time, max_time
FROM pg_stat_statements
WHERE mean_time > 1000
ORDER BY total_time DESC;

-- Ask Claude: "Write a script that checks this view hourly
-- and alerts when queries cross 2-second threshold"

MySQL Slow Log Analysis

# Enable slow log
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

# Analyze with AI
mysqldumpslow -s c -t 10 /var/log/mysql/slow-query.log | \
  xargs -I {} echo "Query: {}. How can I optimize this?"

Real-World Example: N+1 Query Problem

Original problem (slow):

# Django ORM
for order in Order.objects.filter(created_at__gte=thirty_days_ago):
    print(order.customer.name)  # Triggers 1 query per order!
    for item in order.items.all():  # Another query per order!
        print(item.product.name)

Ask Claude: “My Django code runs 100,000 queries for 1000 orders. Fix it.”

Claude response:

# Optimized: Use select_related and prefetch_related
orders = Order.objects.filter(
    created_at__gte=thirty_days_ago
).select_related('customer').prefetch_related('items__product')

for order in orders:
    print(order.customer.name)  # No extra query
    for item in order.items.all():
        print(item.product.name)  # No extra query

Step 5: Query Refactoring Patterns

AI tools excel at suggesting query rewrites. Common patterns:

Convert Subquery to JOIN

-- Slow: subquery executed for each row
SELECT * FROM orders o
WHERE customer_id IN (
  SELECT customer_id FROM customers WHERE status = 'premium'
);

-- Fast: converted to JOIN by Claude
SELECT o.* FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id
WHERE c.status = 'premium';

Move Aggregation Earlier

-- Slow: aggregates ALL rows first
SELECT customer_id, SUM(amount)
FROM orders
WHERE created_at > DATE '2026-01-01'
GROUP BY customer_id;

-- Fast: filter before grouping
SELECT customer_id, SUM(amount)
FROM orders
WHERE created_at > DATE '2026-01-01'
GROUP BY customer_id;

Benchmarking Your Improvements

Test Claude’s recommendations with before/after queries:

import time
from sqlalchemy import text

def benchmark_query(engine, query_name, sql):
    start = time.time()
    with engine.connect() as conn:
        conn.execute(text(sql))
    elapsed = time.time() - start
    return elapsed

original_time = benchmark_query(engine, "original", original_sql)
optimized_time = benchmark_query(engine, "optimized", optimized_sql)

improvement = ((original_time - optimized_time) / original_time) * 100
print(f"Performance improvement: {improvement:.1f}%")
print(f"Original: {original_time:.2f}s → Optimized: {optimized_time:.2f}s")

Common Pitfalls with AI Database Advice

  1. Assuming one index fits all queries: AI might suggest an index that helps query A but hurts query B (update performance).
  2. Not considering write performance: Adding indexes speeds reads but slows inserts/updates.
  3. Ignoring query plan caching: Some optimization suggestions change what the planner chooses next time.
  4. Database stats are stale: AI’s suggestions depend on accurate ANALYZE results. Run ANALYZE before asking.
  1. Daily: Use Claude to review yesterday’s slow queries
  2. Weekly: Ask AI to suggest unused index cleanup
  3. Monthly: Have Claude analyze full execution plan logs and recommend schema changes
  4. Quarterly: Refactor queries that improved little from indexing

Built by theluckystrike — More at zovo.one