In this session, we’ll explore two complementary approaches to understanding Forge SQL performance: profiling slow queries and diagnosing failed ones. First, we’ll see how to use dbExecutionTime to aggregate total database execution time across a single invocation, helping developers detect performance regressions and, when needed, inspect execution plans for individual queries once latency thresholds are exceeded.

Then, we’ll focus on automating the analysis of failed queries, such as those that return: “Your query has been cancelled due to exceeding the allowed memory limit for a single SQL query.” or “The provided query timed out from database.”

You’ll learn how to automatically detect these errors by inspecting their SQL error codes, trigger follow-up queries to Forge SQL metadata tables, and retrieve the corresponding execution plans — all within the same resolver invocation.

This approach enables your app to automatically collect and log diagnostic details for failed queries — even in Forge’s isolated database environment, where direct database access isn’t available.

Finally, we’ll discuss practical optimization strategies — from query rewrites to using @forge/kvs for caching — to improve app performance even when queries can’t be further optimized.

Key takeaways:

• Use dbExecutionTime to measure total database time per invocation and detect performance regressions
• Automatically analyze timeouts and out-of-memory errors by fetching execution plans from metadata tables
• Apply practical optimizations, including caching query results with @forge/kvs, to improve stability when query tuning isn’t enough