Is Laravel bad at scale?

No, and the question is usually the wrong one. Applications that fall over at scale do so because of their database, their queue design or a cache nobody measured, all of which survive a framework change untouched. Laravel runs on large systems; what does not run on large systems is an unindexed join.

Is PHP the problem rather than Laravel?

Sometimes, and specifically where the work is long-lived, concurrent and connection-heavy - the request-per-process model is a poor fit for that shape no matter which framework sits on top. Modern PHP is fast and modern Laravel is well built; what has not changed is what the runtime is designed for.

We already built it in Laravel and now it does not fit.

That is usually one component rather than the whole application, and the answer is to move that component rather than the application. A websocket server or a compute-heavy pipeline can run in something else and talk to the Laravel application, which keeps the rest of the system where it is.

Should we rewrite to something else?

Almost never, and least of all while the reason is unclear. Find out what is actually costing you first - if it is a slow endpoint or a fragile deploy, a rewrite changes neither and costs a year.

When Laravel Is the Wrong Choice

Laravel is a good default and a bad universal. Six situations where it is the wrong tool, written by people who sell Laravel work and would rather not sell it to you twice.

Published September 21, 20264 min readUpdated September 23, 2026

We sell Laravel engineering. That is a reason to be suspicious of an article like this and also a reason it is worth writing: the expensive version of this conversation is the one that happens two years in, and we would rather have it now.

Laravel is a very good default for a web application with a database behind it. Here is where it is not.

1. The work is mostly CPU, not mostly waiting

Image and video processing, large-scale numerical work, model training or inference, anything that keeps a core busy for seconds.

PHP is not a bad language for computation, but the request-per-process model means a heavy job occupies a worker for its duration. Push that into a queue and you have moved it, not solved it - you now need a worker fleet sized for the heaviest job.

What works is Laravel as the application, with the heavy step running somewhere suited to it and communicated with as a service. What does not work is trying to make PHP the compute tier.

2. Thousands of persistent connections

A chat system, live collaborative editing, a game server, a trading feed - anything where clients hold a connection open and receive pushes.

The model is process-per-request. Long-lived connections are the opposite shape, and while there are ways to bolt this on, you are working against the runtime rather than with it. A dedicated realtime server alongside your Laravel application is the arrangement that works, and it is also the one you will arrive at eventually anyway.

Note the boundary, because it matters: occasional notifications pushed to a browser are fine and well supported. It is sustained fan-out at volume that does not belong here.

3. Hard latency guarantees

Sub-millisecond, consistently, at the ninety-ninth percentile. Ad bidding, market data, telemetry ingestion at very high rates.

Booting a framework per request - even a fast one, even with an opcode cache - is not how you reach that budget. A long-running runtime removes the boot, and at that point you are asking PHP to be something it was not designed to be when several other languages already are it.

4. There is no web layer at all

A CLI tool, a desktop application, a daemon, a library other developers will install. Laravel brings an HTTP kernel, a routing layer, a container configured for a web application and a directory structure shaped like a site. If none of that is used, it is weight without benefit.

For a console tool, Laravel's own console components are available on their own. For a library, a library.

5. The team does not write PHP

A team of three who are strong in another language and have never shipped PHP will produce a better application in what they know. Framework quality is a smaller factor than fluency, and it is not close.

The counter-case is hiring: if you expect to grow the team, the PHP and Laravel hiring pool is large and the onboarding is short. That is a real argument for choosing it deliberately - but it is an argument about eighteen months from now, not about this quarter.

6. A product already exists that does it

The most common one, and the one that costs the most when ignored. A shop with a simple catalogue, a blog, a booking page, an internal form.

Custom software is a liability you maintain forever. A platform is a subscription you can cancel. Building should start when the platform is demonstrably the thing costing you money - which is a recognisable point, not a feeling.

Where the answer is yes

A web application with a relational database, users with roles, background work, third-party integrations, an admin side, and a team that will change over the years. That is most business software, and Laravel is genuinely excellent at it.

The framework does not decide whether that application survives. What decides it is the schema, whether jobs are safe to run twice, whether anybody is watching the queue, and whether the tests would notice a regression. An application that gets those right is maintainable in Laravel and in anything else. One that gets them wrong is not saved by the language it is written in.

This page answers the general question. If you have already narrowed it to two candidates, the specific comparison is the better read: Symfony where the argument is how much of the architecture you want handed to you, Rails if the shortlist is two opinionated full-stack frameworks, Django when the team's other language is Python, and Node when what you are building is an API and nothing else.

The case this page does not cover is the one where the product is content rather than behaviour. There the alternative is not another framework, and the comparison worth reading is WordPress, where our answer is more often than not that you should stay where you are.