View SQL Queries in Laravel: all the ways to inspect and debug your queries

When we develop applications in Laravel, much of the magic happens thanks to Eloquent and the Query Builder. We write clean, expressive code... but under the hood, Laravel is generating real SQL queries that directly impact performance.

In my experience, the first step to optimizing a Laravel application is not to touch indexes or cache, but something much more basic: to see exactly what SQL queries are being executed and when.

In this post, I bring you all the practical ways to see SQL queries in Laravel made by request. When we create a Laravel app, many requests can be made by us or internally by Laravel. Since we have great freedom when creating our requests, it is very likely that we make mistakes in some parts and create poorly optimized queries. The first step to correcting these problems is to see the query.

All of this is part of a CRUCIAL task in our applications, which is to debug our apps in Laravel using a debugbar

Why is it important to see SQL queries in Laravel?

Common problems: N+1 queries, performance, and unnecessary overhead

One of the most common scenarios is loading a seemingly simple view and discovering that:

• Dozens of queries are executed
• Many are repeated
• Others access relationships you don't need

When this happens to me, there is almost always an N+1 problem, a poorly loaded relationship, or unclear data access logic behind it.

Eloquent and Query Builder: what really happens in the database

Although Eloquent abstracts us from SQL, the database still receives raw queries. Seeing them allows you to:

• Understand how Laravel translates your code
• Detect slow queries
• Validate that with() works as you expect

Using Laravel Debugbar to see SQL queries per request (recommended)

If I had to recommend a single tool for development, it would be this one.

In my day-to-day, when I notice that a page starts to run slow, I activate Debugbar and review the request's queries. It is immediate and very visual.

What information Debugbar shows about SQL queries

Laravel Debugbar allows you to see:

• All executed SQL queries
• Execution time of each query
• Bindings
• Total number of queries per request

Method 1: Laravel's Built-in Logging System

Using the DB::listen method, you can listen for database query events and do whatever you want with them, such as logging the queries or displaying them on the screen.

Basic implementation with DB::listen in a ServiceProvider

use Illuminate\Support\Facades\DB;
public function boot()
{
    DB::listen(function ($query) {
        \Log::info($query->sql, ['bindings' => $query->bindings, 'time' => $query->time]);
    });
}

Or in the routes:

routes/web.php

DB::listen(function ($query){
    echo $query->sql;
  //  Log::info($query->sql, ['bindings' => $query->bindings, 'time' => $query->time]);
});

Log SQL queries in custom logs

This allows you to:

• Review all executed queries
• Analyze patterns
• Audit performance

I only use it temporarily, when I need to investigate something specific.

Why you should never use DB::listen in production

Because:

• It runs on every query
• It generates overhead
• It can produce giant logs

Method 2: Laravel Debugbar Package

Laravel Debugbar is an excellent tool for debugging in the app. It gives us a lot of information about what is happening, including the SQL queries, and it also gives us the execution time:

composer require barryvdh/laravel-debugbar

Method 3: Using Laravel Telescope

Laravel Telescope is the official tool from the Laravel team for debugging and monitoring. It is the previous package, but with vitamins:

composer require laravel/telescope

Then, run the Telescope installation and migration command:

php artisan telescope:install
php artisan migrate

Method 4: See the SQL generated by Eloquent with the toSql() method

The toSql method converts the Eloquent query into SQL text so that we can see how Laravel internally translates a query to SQL and be able to analyze it. It is ideal for debugging:

$sql = DB::table('posts')->where('posted', true)->toSql();

What toSql really shows and its limitations

• Shows only the base query
• Does not execute the query
• Does not include real values (bindings)

Why toSql is not enough for Eloquent relationships

A common mistake is to think that toSql() shows everything. It doesn't when there are with() relationships. That's why I rarely use it as the only tool.

Method 5: Using the DB::getQueryLog Method

Another approach is using DB::getQueryLog to get all the SQL queries executed during the current request. For example:

DB::enableQueryLog();
// Perform some query operations
$queries = DB::getQueryLog();

This will return an array with all the executed SQL queries.

How to enable and read the Query Log

It returns an array with:

• Query
• Bindings
• Execution time

Cases in which this method does make sense

• One-off scripts
• Tests
• Very controlled debugging

How to see the SQL of Eloquent relationships and detect N+1 problems

This is where the real problems usually appear.

What happens internally when using with()

When you use:

Post::with('comments')->get();

Laravel generates:

• A main query
• One or more additional queries per relationship

How to identify duplicate or unnecessary queries

With Debugbar or QueryLog you can quickly see:

• Repeated queries
• Unnecessary accesses
• Poorly loaded relationships

When I see many similar queries, I know that something can be optimized.

Inspect SQL queries interactively with Tinkerwell

For one-off debugging, Tinkerwell is very useful.

When to use Tinkerwell instead of Debugbar

• Quick tests
• Analysis of a specific query
• Without affecting the application

One-off debugging without affecting the application

You can run Eloquent, Query Builder and see the SQL without having to load a full view.

Common errors when debugging SQL queries in Laravel

• Relying only on toSql
  • It does not show relationships or real values.
• Leaving debug tools active in production
  • A serious error that impacts performance and security.
• Misinterpreting bindings and execution times
  • The SQL may seem fast, but the number of queries also matters.

What method to use depending on the scenario (quick guide)

• Quick debugging in development
  • Laravel Debugbar
• Performance analysis
  • Laravel Pulse / Telescope
• Logging and auditing of queries
  • DB::listen() (only locally)

Frequently asked questions about viewing SQL queries in Laravel

• How to see the SQL that Eloquent generates?
  • With Debugbar, QueryLog or toSql() (depending on the case).
• What is the best way to see SQL queries in Laravel?
  • For development, Debugbar. For performance, Pulse.
• Is it safe to use Debugbar in production?
  • No, never.
• How to detect N+1 queries in Laravel?
  • By checking the number of queries per request with Debugbar or Telescope.

Conclusion

Viewing SQL queries in Laravel is not optional if you care about performance. In my experience, spending a few minutes inspecting queries usually saves hours of unnecessary optimization.

Use the right tool for the context, understand what's happening under the hood, and let Laravel do its job... but with your eyes wide open.

These are just a few ways you can implement in your code to see the SQL of the queries made.

Now, learn to use Queues and Jobs to postpone Tasks in Laravel.