Laravel 13.36 fills the validation builder gaps

String rules become harder to maintain over time

String-based validation rules work, but they become awkward once they collect parameters, related fields, and exceptions. A misplaced comma or parameter can alter a rule without giving the editor much chance to help. Laravel 13.36 expands Rule:: builders to cover rules that previously relied only on string syntax.

The validation behaviour itself does not change; the declaration becomes more explicit. I get autocomplete, chainable methods, and less string assembly in Form Requests that already contain enough moving parts. It is also easier to review a rule when its conditions are represented by PHP method calls. (laravel.com)

use Illuminate\Validation\Rule;
 
$request->validate([
    'website' => ['nullable', Rule::url()->protocols(['https'])],
    'device_id' => [Rule::uuid()->version(4)],
    'tags.*' => [Rule::distinct()->ignoreCase()],
    'phone' => [Rule::requiredWithout('email')],
]);

There is no need to migrate every existing validator at once. I would start with conditional rules, value lists, and validations currently built through string interpolation. Those are the places where a fluent API removes the most ambiguity and makes later changes less brittle.

Analytical queries without leaving OLAP mode enabled

The other practical addition is aimed at MySQL connections running on Vitess, including PlanetScale. Laravel adds olap() to the connection so an analytical query can run inside a callback. It sets the OLAP workload on both read and write connections for that callback, then restores OLTP afterwards, including when an exception is thrown. (laravel.com)

use Illuminate\Support\Facades\DB;
 
$totals = DB::connection('mysql')->olap(
    fn ($connection) => $connection->table('orders')
        ->selectRaw('customer_id, sum(total) as total')
        ->groupBy('customer_id')
        ->get()
);

This avoids manually issuing set workload statements and having to guarantee cleanup afterwards. Laravel’s documentation also states that the callback runs without changing the workload on MySQL connections that are not using Vitess. That makes it possible to keep the same application code locally and in production, provided the query itself works in both environments. (laravel.com)

Workers that do not carry sticky state forward

Queue workers are long-lived processes, so database connection state matters. When a read/write connection uses sticky, a write can cause subsequent reads to stay on the write connection. In a worker, that state can outlive the job that triggered it and affect later jobs handled by the same process. (github.com)

Laravel 13.36 adds an explicit opt-in switch to clear that state between jobs. It is configured from a service provider and remains disabled by default. For self-hosted applications with read replicas and persistent workers, this is worth reviewing before assuming replicas are receiving their intended share of reads.

namespace App\Providers;
 
use Illuminate\Queue\Worker;
use Illuminate\Support\ServiceProvider;
 
class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Worker::$flushStickyConnections = true;
    }
}

The fine print before upgrading

Builders do not make a validation rule stricter on their own: they change how it is declared, not what it validates. They also do not replace integration tests when a rule relies on real data, DNS, or database constraints. Update the framework first and confirm that the selected method exists in the installed version before replacing existing string rules.

olap() does not turn an inefficient query into an efficient one, and it is not a general-purpose database feature. It is designed for MySQL connections using Vitess, with the benefit of applying the workload only for a bounded callback. Likewise, enabling Worker::$flushStickyConnections may be unsuitable if a workflow deliberately relies on sticky state across jobs; that dependency should be reviewed and represented explicitly through chains, batches, or durable storage.

A small release with everyday consequences

I do not see Laravel 13.36 as a reason to rewrite validators for style alone. It is a sensible opportunity to clean up complex rules, wrap Vitess analytical queries safely, and inspect how persistent workers behave in production. These are small changes, but they target three areas where Laravel projects tend to accumulate hidden assumptions.

Source: Laravel News Official documentation: validation, database, worker source