{"slug": "5-things-ai-cannot-do-at-postgresql", "title": "5 Things AI Cannot Do at PostgreSQL", "summary": "A developer argues that AI tools, despite their growing proficiency at writing PostgreSQL queries and reading EXPLAIN ANALYZE output, still fall short in five areas of database work: understanding business context behind data, weighing trade-offs such as index overhead, diagnosing multi-signal performance incidents involving MVCC and vacuum behavior, and handling security and responsibility decisions. The piece contends that AI can list options and summarize logs, but humans must decide what matters for a given system.", "body_md": "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.\n\nThat is useful. But there is a difference between **writing PostgreSQL code** and **understanding why the database should work that way**.\n\nAfter 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.\n\nThis is probably the easiest mistake to make because the SQL can look completely correct.\n\nImagine someone asks:\n\n“Show total customer revenue for this year.”\n\nAI can produce a query immediately. But what does “revenue” mean in your application?\n\nDoes it include refunds? Discounts? Tax? Returned products? An order created in December but refunded in January?\n\nThose are **business questions**, not SQL questions.\n\nFor example:\n\n```\nSELECT customer_id, SUM(total)\nFROM orders\nWHERE created_at >= '2026-01-01'\nGROUP BY customer_id;\n```\n\nThe query is valid. It can still be completely wrong.\n\nA 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.\n\nThat creates a dangerous type of result: a query that looks reasonable enough to survive a quick code review while producing the wrong answer.\n\nPostgreSQL 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.\n\nThe difficult part is not knowing these options exist. It is deciding **which cost you are willing to pay**.\n\nTake indexes:\n\n```\nCREATE INDEX idx_orders_customer_id\nON orders(customer_id);\n```\n\nAn 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.\n\nThe 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.\n\nAI can list the choices. **A person still has to decide what matters most** for this particular system.\n\nThis is where database work becomes much less like writing code.\n\nSuppose an application suddenly becomes slow. CPU is only 25%. Memory looks fine. The network seems normal.\n\nThen you notice old row versions, unusual vacuum behavior, stale statistics, and blocked sessions.\n\nNow you have a detective story.\n\nPostgreSQL 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.\n\nAI can read logs, summarize `pg_stat_statements`, and explain an execution plan. The difficult part is connecting several weak signals into one explanation.\n\n```\nSELECT pid,\n       wait_event_type,\n       wait_event,\n       query\nFROM pg_stat_activity\nWHERE wait_event IS NOT NULL;\n```\n\nThat output is evidence. It is not the diagnosis.\n\nMaybe 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.\n\nThis 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.\n\nPostgreSQL has roles, grants, and row-level security. AI can help write policies and spot obviously broad permissions.\n\nBut security is not only a SQL problem.\n\nImagine the requirement is: “Support agents can see customer records.”\n\nShould they see addresses? Payment information? Internal notes? Deleted accounts? Customers from another region?\n\nAn AI model could generate:\n\n```\nCREATE ROLE support_agent;\n\nGRANT SELECT ON customers TO support_agent;\n```\n\nThe SQL is fine. The policy could still be terrible.\n\nReal 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.\n\n**AI can suggest a control. It cannot own the consequences of choosing it.**\n\nThis is probably the most interesting limitation.\n\nAI is very good at combining known patterns. PostgreSQL has decades of documentation, discussions, bug reports, and production experience for a model to learn from.\n\nBut sometimes there is no established answer.\n\nThe 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.\n\nWhen a production system has an unusual workload and a failure mode nobody has seen before, you have to experiment.\n\nBuild a small reproduction. Change one variable. Compare plans. Maybe the first idea fails.\n\nThat loop of **hypothesis → experiment → failure → adjustment** is still a major part of database engineering.\n\nNone of this means AI is bad at PostgreSQL. Quite the opposite.\n\nIt is excellent for repetitive work. It can generate SQL, explain commands, draft migrations, summarize logs, and give you another angle when you are stuck.\n\nThe important distinction is **assistance versus authority**.\n\nI would happily ask AI to draft:\n\n```\nALTER TABLE users\nADD COLUMN last_login_at timestamptz;\n```\n\nI would not blindly run a risky production migration just because the generated SQL looks correct.\n\nPostgreSQL 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.\n\nThe 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.\n\nWriting a basic query may take seconds now.\n\nUnderstanding whether that query belongs in production can take much longer.\n\nAI 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.\n\nThat is probably the most useful way to think about AI in PostgreSQL.\n\n**Use AI to move faster, but do not confuse a plausible answer with a verified one.**\n\nThe database still needs someone who understands the system behind the SQL.", "url": "https://wpnews.pro/news/5-things-ai-cannot-do-at-postgresql", "canonical_source": "https://dev.to/devunionx/5-things-ai-cannot-do-at-postgresql-4kj8", "published_at": "2026-09-16 21:55:53+00:00", "updated_at": "2026-09-16 22:53:09.358744+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products"], "entities": ["PostgreSQL"], "alternates": {"html": "https://wpnews.pro/news/5-things-ai-cannot-do-at-postgresql", "markdown": "https://wpnews.pro/news/5-things-ai-cannot-do-at-postgresql.md", "text": "https://wpnews.pro/news/5-things-ai-cannot-do-at-postgresql.txt", "jsonld": "https://wpnews.pro/news/5-things-ai-cannot-do-at-postgresql.jsonld"}}