iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Laravel queries begin as fluent PHP calls, but they are not simply SQL strings assembled as you type. The Query Builder represents a query as components and value bindings; a database-specific grammar prepares it for execution, and a connection runs it. Eloquent builds on that layer with model behavior. Understanding those boundaries helps you choose the right API, inspect what runs, and avoid unsafe assumptions about parameter binding.
What happens when you build a Laravel query?
Laravel offers several ways to interact with a database: raw SQL, the Query Builder, and Eloquent. The Query Builder is a fluent interface for creating and running queries. You can start with a table using DB::table(...) or start with an Eloquent model, then express operations such as selecting columns, joining tables, filtering, grouping, ordering, and limiting results.
For example, a table query might look like this:
$users = DB::table('users')
->where('active', true)
->orderBy('name')
->get();
The calls describe the desired query in PHP. Conceptually, the builder maintains query state—such as columns, joins, where clauses, groupings, ordering, limits, offsets, and unions—alongside bindings for values. The API also identifies a connection, grammar, and processor as distinct parts of the builder. This is a useful map of its responsibilities, not a claim that every method follows an identical internal path. See the Laravel 13.x Query Builder API reference.
How does Laravel turn a builder into SQL and run it?
The grammar is the component associated with representing a query for a database driver, while the connection handles execution. Since database engines differ, the SQL produced is not guaranteed to be identical across drivers. The broad lifecycle is: build query state, prepare driver-appropriate SQL with value placeholders, then pass the statement and bindings to the connection for execution. Laravel’s 13.x Connection source shows query execution being reported through a QueryExecuted event that includes SQL, bindings, elapsed time, and whether the query used a read or write connection.
#1 Best Overall
Bindings matter for both correctness and security. Laravel uses PDO parameter binding for values such as a name or status in a where condition. But PDO cannot bind identifiers: a placeholder cannot safely stand in for a column name, table name, or sort direction. Do not let request input directly choose an orderBy column or other SQL identifier. Instead, validate it against an explicit allowlist and select a known identifier.
Raw expressions are different: they enter as SQL strings rather than ordinary bound values. Bindings do not sanitize an arbitrary SQL fragment. Construct raw expressions from trusted, constant SQL and validate any dynamic choices before incorporating them. Laravel documents these constraints in its Query Builder documentation.
What is the difference between raw SQL, Query Builder, and Eloquent?
| Layer | How you express work | Typical result and behavior | Control and composition |
|---|---|---|---|
| Raw SQL | Write SQL directly and execute it through Laravel’s database facilities. | Database results rather than model instances by default; it does not provide Eloquent’s per-model lifecycle behavior. | Most direct control over SQL; reusable composition depends on how you organize the SQL and bindings. |
| Query Builder | Chain fluent PHP methods from DB::table(...). |
Database result objects or scalar values depending on the operation; no Eloquent model lifecycle for ordinary builder operations. | Composes selects, writes, conditions, joins, aggregates, locks, and more without requiring SQL strings for every operation. |
| Eloquent | Start from a model and build a model-oriented query. | Retrieves and persists model instances, enabling model relationships and lifecycle events in applicable operations. | Higher-level model semantics, with the ability to express queries through the underlying builder APIs. |
These are abstraction choices, not a performance ranking. Laravel’s documentation describes their capabilities, but it does not establish a universal speed order; performance depends on the query, database, data, and execution context. Consult the database documentation and Eloquent documentation for their respective APIs.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What does Eloquent add—and when do mass operations differ?
Eloquent maps models to database tables and provides model-oriented retrieval and persistence. When Laravel retrieves or saves individual models through operations that involve those model instances, model lifecycle events can be relevant. This makes Eloquent useful when application behavior belongs to each model rather than only to the set of rows being changed.
Rank #3
Mass updates and deletes behave differently. They operate as set-based database queries and do not retrieve each affected model, so Laravel does not dispatch the per-model saving, saved, updating, updated, deleting, or deleted events for those affected records. If application logic depends on those events, a bulk operation will not provide that per-instance lifecycle. Laravel explains this in its Eloquent documentation.
How can you see the SQL query in Laravel?
For a builder you are still composing, inspect its SQL and bindings using the builder’s SQL-and-bindings debugging facilities. This helps distinguish the SQL structure from the values that will be bound; do not treat a display of SQL with interpolated values as proof that values were concatenated into the statement.
Rank #4
To observe statements that actually execute, register a database query listener. Laravel also supports monitoring cumulative query time. Query time is execution context—it can help identify where to investigate, but one observation alone is not a benchmark or a diagnosis of the cause.
Recommended Free Tools
use IlluminateDatabaseEventsQueryExecuted;
use IlluminateSupportFacadesDB;
DB::listen(function (QueryExecuted $query) {
logger()->debug('Database query executed', [
'sql' => $query->sql,
'bindings' => $query->bindings,
'time_ms' => $query->time,
]);
});
Place the listener where it is registered for the application lifecycle you intend to observe, and avoid exposing sensitive bindings in production logs. The database documentation covers query listeners and cumulative query-time monitoring; the API reference documents builder inspection methods, and the connection source shows the execution event’s SQL, bindings, elapsed time, and read/write type.
Best Value
Which layer should you use?
- Use raw SQL when the SQL itself is the clearest way to express a database-specific operation, and handle values through bindings.
- Use Query Builder for composable table-level reads and writes when model lifecycle behavior is unnecessary.
- Use Eloquent when model instances, relationships, and model-oriented application behavior are central to the operation.
The documentation cited here is for Laravel 13.x, and the framework source link points to the 13.x branch. Laravel’s database getting-started documentation lists first-party support for five database families; the exact minimum database versions and feature compatibility depend on the release and driver in use, so check those details for your deployment rather than assuming every driver behaves alike.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

