5 Things AI Cannot Do at PostgreSQL

AI has become surprisingly good at PostgreSQL. Give it a schema and it can write a query in seconds. Paste an EXPLAIN ANALYZE result into a chat and it may suggest an index or point to an expensive join.

That is useful. But there is a difference between writing PostgreSQL code and understanding why the database should work that way.

After looking at the practical side of PostgreSQL, five gaps stand out. They are less about syntax and more about context, trade-offs, investigation, responsibility, and situations where there is no obvious answer.

1. AI Cannot Understand Your Business Logic

This is probably the easiest mistake to make because the SQL can look completely correct.

Imagine someone asks:

“Show total customer revenue for this year.”

AI can produce a query immediately. But what does “revenue” mean in your application?

Does it include refunds? Discounts? Tax? Returned products? An order created in December but refunded in January?

Those are business questions, not SQL questions.

For example:

SELECT customer_id, SUM(total)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY customer_id;

The query is valid. It can still be completely wrong.

A developer who knows the system will ask which table is authoritative, what the order data represents, and whether total is gross or net. AI may not know any of that unless the context is provided.

That creates a dangerous type of result: a query that looks reasonable enough to survive a quick code review while producing the wrong answer.

2. AI Cannot Make the Architecture Trade-Off for You

PostgreSQL gives you many options. You can add indexes, partition tables, change memory settings, introduce replicas, redesign a schema, or add an extension for a specialized workload.

The difficult part is not knowing these options exist. It is deciding which cost you are willing to pay.

Take indexes:

CREATE INDEX idx_orders_customer_id
ON orders(customer_id);

An AI assistant may suggest this after seeing a slow query. It might help, but every index also consumes storage and adds maintenance work. On a write-heavy system, too many indexes can hurt INSERT and UPDATE performance.

The same thing happens with larger architecture decisions. A time-series workload may push you toward partitioning or an extension. A busy application may need pooling or read replicas. Memory settings depend on total RAM, concurrent workloads, and query behavior.

AI can list the choices. A person still has to decide what matters most for this particular system.

3. AI Cannot Reliably Find the Root Cause of a Production Incident

This is where database work becomes much less like writing code.

Suppose an application suddenly becomes slow. CPU is only 25%. Memory looks fine. The network seems normal.

Then you notice old row versions, unusual vacuum behavior, stale statistics, and blocked sessions.

Now you have a detective story.

PostgreSQL uses MVCC, so concurrent transactions work with snapshots and older row versions may remain until they can be cleaned up. PostgreSQL also has several isolation levels, row and table locks, deadlocks, and serialization failures.

AI can read logs, summarize pg_stat_statements, and explain an execution plan. The difficult part is connecting several weak signals into one explanation.

For example:

SELECT pid,
       wait_event_type,
       wait_event,
       query
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;

That output is evidence. It is not the diagnosis.

Maybe PostgreSQL is the problem. Maybe an ORM created an N+1 query pattern. Maybe a deployment changed transaction behavior. Maybe a cleanup job created severe bloat.

This is exactly the kind of PostgreSQL troubleshooting where symptoms can point in several directions at once. The provided research highlights how vacuum behavior, statistics, locks, storage, and application behavior can interact in ways that are not obvious from a single metric.

4. AI Cannot Take Responsibility for Security Decisions

PostgreSQL has roles, grants, and row-level security. AI can help write policies and spot obviously broad permissions.

But security is not only a SQL problem.

Imagine the requirement is: “Support agents can see customer records.”

Should they see addresses? Payment information? Internal notes? Deleted accounts? Customers from another region?

An AI model could generate:

CREATE ROLE support_agent;

GRANT SELECT ON customers TO support_agent;

The SQL is fine. The policy could still be terrible.

Real security decisions involve risk tolerance, internal rules, auditing, incident response, and sometimes legal obligations. AI can help draft controls, but humans still decide what risk is acceptable and what happens when something goes wrong.

AI can suggest a control. It cannot own the consequences of choosing it.

5. AI Cannot Invent the Right Answer When the Problem Is New

This is probably the most interesting limitation.

AI is very good at combining known patterns. PostgreSQL has decades of documentation, discussions, bug reports, and production experience for a model to learn from.

But sometimes there is no established answer.

The research report points to ongoing PostgreSQL discussions around issues such as global indexes for partitioned tables. These problems involve deep trade-offs and active experimentation rather than one universal best practice.

When a production system has an unusual workload and a failure mode nobody has seen before, you have to experiment.

Build a small reproduction. Change one variable. Compare plans. Maybe the first idea fails.

That loop of hypothesis → experiment → failure → adjustment is still a major part of database engineering.

AI Is a PostgreSQL Tool, Not a PostgreSQL Engineer

None of this means AI is bad at PostgreSQL. Quite the opposite.

It is excellent for repetitive work. It can generate SQL, explain commands, draft migrations, summarize logs, and give you another angle when you are stuck.

The important distinction is assistance versus authority.

I would happily ask AI to draft:

ALTER TABLE users
ADD COLUMN last_login_at timestamptz;

I would not blindly run a risky production migration just because the generated SQL looks correct.

PostgreSQL is full of decisions where correctness depends on context: schema design, indexing, concurrency, vacuum behavior, permissions, and operational constraints. PostgreSQL's current documentation also treats concurrency as a broader system involving isolation, locks, deadlocks, and serialization failures rather than a single setting or command.

The Human Part Still Matters

The interesting thing about AI and PostgreSQL is that the technology does not necessarily remove the need for database engineers. It changes where their time is spent.

Writing a basic query may take seconds now.

Understanding whether that query belongs in production can take much longer.

AI can generate the first version. A developer can then test it, question its assumptions, compare the execution plan, check the business rules, and decide whether the result actually makes sense.

That is probably the most useful way to think about AI in PostgreSQL.

Use AI to move faster, but do not confuse a plausible answer with a verified one.

The database still needs someone who understands the system behind the SQL.