Laravel 13 released on Tuesday with a queue system rebuilt on PHP fibers, replacing the process-per-worker model that has defined PHP background processing since the language got background processing. A single Laravel worker process can now run hundreds of concurrent jobs, suspending each one when it blocks on a database query or an HTTP request rather than sitting idle. Memory per concurrent job dropped from roughly 40 megabytes, the cost of a separate PHP process, to about 900 kilobytes. For applications whose queue work is dominated by waiting on external services, which describes most of them, this is the largest efficiency change Laravel has made in a decade.
How PHP got here
PHP 8.1 introduced fibers in 2021, giving the language a coroutine primitive without the ecosystem-splitting extensions that ReactPHP, Amp, and Swoole had built. Fibers alone do nothing useful: a fiber that calls a blocking database function still blocks. Making them worthwhile required non-blocking implementations of the input and output that applications actually perform, which is why the feature sat mostly unused for four years.
export async function handler(request: Request): Promise<Response> { const started = Date.now(); const upstream = await fetch(request); const headers = new Headers(upstream.headers); headers.set("x-skarvonix-ms", String(Date.now() - started)); return new Response(upstream.body, { status: upstream.status, headers, });}Laravel 13's queue system builds on Revolt, the event loop that Amp maintains, plus non-blocking drivers for MySQL, PostgreSQL, Redis, and HTTP through a rewritten client. When a job awaits a query, the fiber suspends and the scheduler runs another job. The application code looks the same, which is the important part: developers write ordinary synchronous-looking code and the framework handles suspension.
The performance in practice
Laravel's benchmark, which several teams have reproduced, runs a job that makes three HTTP calls averaging 200 milliseconds each and writes to a database. Under the old model, sixteen worker processes on a 4 gigabyte container processed about 26 jobs per second. Under fibers, one process on the same container handled 340. The bottleneck moved from process memory to the database connection pool, which is a much better place for it to be.
For CPU-bound jobs, image processing or large data transformation, the improvement is nothing, because fibers do not add parallelism. Those jobs still need multiple processes across multiple cores, and Laravel 13 supports running fiber workers across processes for exactly that reason. The guidance in the upgrade documentation is direct about which workloads benefit, which is more honest than framework release notes usually are.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
What breaks
Any code holding state in a static property or a singleton across a job boundary is now dangerous, because multiple jobs share a process. That pattern was always questionable and was harmless under process isolation, which means a large amount of existing code depends on isolation it never declared. Laravel ships a static analysis rule that flags suspicious patterns, and it produces false positives.
Third-party packages are the bigger issue. Any package using a blocking client for an external service will block the entire event loop when called from a fiber, stalling every other job in that process. Laravel maintains a compatibility list, and the major packages have been updated, but a payment SDK or a monitoring agent using raw cURL will silently destroy the concurrency benefit. The framework detects long blocking calls and logs a warning, which is the practical way most teams will find these.
The rest of the release
Laravel 13 also ships a rewritten Eloquent query builder with better type inference, which makes static analysis tools substantially more useful on model queries. The validation system gained conditional rule sets that read better than the nested closures the previous version required. And the framework's first-party testing tools gained a database transaction mode that is roughly 40 percent faster for suites with heavy fixture setup.
Taylor Otwell also announced that Laravel Cloud, the company's hosting product launched in 2025, will support the fiber queue model with automatic worker scaling based on queue depth and fiber utilization rather than on process count. That is a straightforward commercial tie between the open source work and the business, and it is the model Laravel has run successfully with Forge and Vapor for years.
What this means for PHP
PHP has spent a decade being written off and has kept a large share of web development, particularly in Europe and in the mid-market. Its persistent technical weakness against Node, Go, and Python has been concurrency, and the standard answer was that PHP's process model is simple and simplicity has value. That answer was true and it cost real money in server capacity.
Laravel implementing fibers properly in the framework most PHP developers use makes the capability available without adopting Swoole or restructuring an application. If the ecosystem's blocking clients get replaced over the next two years, PHP's concurrency story becomes ordinary rather than a liability. That is a bigger deal for the language than any syntax addition in recent memory, and it happened in a framework release rather than a language one.
The comparison worth making is against Symfony, which has taken a more conservative path and has a substantial enterprise base that values exactly that conservatism. Symfony's maintainers have discussed fibers and have not made them a default anywhere, on the reasonable grounds that a framework used in banking and government cannot ship a concurrency model whose failure modes are still being discovered. Both positions are defensible and they will produce visibly different frameworks within two years, which is healthier for PHP than the years when Laravel's direction was effectively the language's direction.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
