From 500ms to 900ms: How AI-Assisted “Optimizations” Turned a Fast Query into a Slow One — and What Brought It Back to 43ms

Modern AI coding assistants are increasingly positioned as tools for improving performance, suggesting optimizations, and accelerating backend development. In practice, their strengths are often concentrated in code generation and pattern completion rather than in understanding the actual behavior of running systems under real constraints.

A recent debugging case illustrates this gap clearly. An API endpoint returning approximately 2,000 database records exhibited a response time of ~500ms on the client side. Initial investigation ruled out the database layer almost immediately, as the raw query execution time inside PostgreSQL was around 2ms. The system was not database-bound; it was execution-path bound.

When the issue was analyzed with an AI assistant, the suggested direction followed a conventional optimization path: increase indexing coverage, adjust ORM loading strategies, introduce scalars().unique(), and refine relationship handling through additional abstraction at the ORM layer. In isolation, these are standard recommendations in ORM-based systems and often valid in large-scale workloads. In this case, they were misaligned with the actual constraint.

After implementation, response time increased from ~500ms to ~900ms. The reason was not a single incorrect change, but the introduction of additional computational layers into a workflow that did not require them. The dataset size remained small enough that PostgreSQL naturally favored hash joins and avoided heavy index utilization. Forcing additional indexing and ORM uniqueness enforcement introduced repeated UUID validation checks and extra iteration steps across the query lifecycle, effectively shifting cost from the database to the application layer.

The resolution came from removing abstraction rather than adding it. Replacing ORM-heavy relationship loading patterns such as joinedload and selectinload with controlled raw SQL queries, combined with explicit pagination and reduced object hydration, eliminated unnecessary overhead in the execution path. The final response time dropped from ~900ms to ~43ms.

The key observation is not that AI suggestions were wrong in principle, but that they optimized for structural correctness rather than contextual necessity. Performance engineering is rarely about applying more patterns. It is about identifying when those patterns no longer fit the scale or shape of the workload.

In database systems, especially those built on ORMs like SQLAlchemy, the most expensive performance issues are often not missing optimizations, but accumulated abstraction: unnecessary joins, redundant object mapping, hidden execution paths, and implicit behavior that only becomes visible under profiling.

As AI-generated code becomes more common in production systems, the core risk is not syntactic error but systematic over-engineering. Code that is correct, idiomatic, and still suboptimal under real constraints. In performance-critical systems, the hardest skill is not knowing what to add. It is knowing what to remove.