Today, when troubleshooting SQL behavior or performance in OutSystems, developers often need to switch between Service Studio and Service Center to understand how queries are being executed. While Service Center is a powerful tool for monitoring, this context switching slows down development and makes it harder to diagnose issues early.

I suggest bringing SQL debugging and monitoring capabilities directly into Service Studio, allowing developers to analyze query behavior while they are building and testing their applications, without relying on Service Center for day-to-day development tasks.

Possible improvements could include:

• Visibility of executed SQL details for Aggregates and Advanced SQL

• Execution time and number of executions shown directly in Service Studio

• Easy navigation from a screen or action to its related SQL performance data

• Optional visualization of execution plans or performance hints during development

This approach would encourage earlier detection of performance issues and improve the overall developer experience.

Use Case 
In a recent project, I had to work with a fairly large Advanced SQL query that contained several CASE WHEN statements to handle different business rules within the same query.

At some point, the screen started returning inconsistent data and, in certain scenarios, became slower than expected. Looking at the SQL itself, it wasn’t clear which CASE branch was actually being used during execution, since the behavior depended on different combinations of parameters coming from the screen.

To investigate, I had to copy the SQL from View SQL, run it manually in the database with different parameter values, and then check the Service Center to see execution times and how often the query was being called. This back-and-forth between Service Studio, the database, and Service Center ended up taking a lot of time.

It would be extremely helpful to be able to add a breakpoint directly in the SQL, at a specific point in the query, similar to how debugging works in Visual Studio. This would make it easier to understand which logical path the query is following, which CASE condition is being met, and whether the parameters are producing the expected behavior.

Having this kind of inspection capability directly in Service Studio, even if limited to development environments, would greatly simplify the process of understanding complex SQL and allow developers to fine-tune queries earlier, without relying on external tools or post-deployment analysis.