DEV Community: Elias Alrgeai

chunk() vs cursor() vs lazy() — I Benchmarked All 3 So You Don't Have To

Elias Alrgeai — Sat, 22 Aug 2026 10:28:02 +0000

I never truly understood the difference between chunk(), cursor(), and lazy(), so I ran a quick test: I seeded 100,000 rows into a table, then looped through all of them 3 times. Once with chunk(), once with cursor(), and once with lazy(), measuring memory usage, query count, and execution time for each one.

Here's what I learned from this test, and why the difference between these three isn't just syntax. It's a real architectural decision that affects your database connections and your app's stability under load.

The Root Problem

Here is what happens when you run something such as User::all() or User::get() on a big table:

The database runs the query: SELECT * FROM users, and hands back every matching row.
PHP turns each row into an Eloquent model: a full object, sitting in memory, for every single row (this is where the issues happen).

The database doesn't struggle with this. MySQL or Postgres can have millions of rows and still be fine. The issue happens in step 2, when PHP attempts to hold every single one of those rows as an object all at once in RAM.

A single hydrated Eloquent model takes up roughly 5 KB to 10 KB of RAM. On a small app with 1000 users, holding every single row from a table as an object in memory isn't an issue. But on an app with 10,000+ users, RAM usage can easily blow past 128 MB, causing a fatal error crashing the entire operation:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.php on line 512

Here is a diagram visualizing the issue:

This issue is exactly why chunk(), cursor(), and lazy() exist. The 3 functions are solutions to this problem, however they have different methods of solving it, and the difference matters significantly.

`chunk()` - Multiple Small Trips

chunk() works by breaking one big query into smaller ones, so your server doesn't have to hold all the rows in memory at once. Instead of hydrating all the rows at once and filling up the server's memory, it performs PHP hydration multiple times, each time with a different group of rows.

User::chunk(200, function ($users) {
    foreach ($users as $user) {
        // process each user
    }
});

Behind the scenes, Laravel actually runs something like SELECT * FROM users LIMIT 200 OFFSET 0, processes that batch, throws it away, then runs LIMIT 200 OFFSET 200. It keeps repeating the process like a loop, until all of the rows are hydrated.

The Twist

When deleting or updating rows while looping, the OFFSET shifts (let's say you're deleting 200 rows at a time, the first 200 rows get deleted, now index 0 has shifted). This causes some rows to get skipped and others processed twice.

The Fix: `chunkById()`

User::chunkById(200, function ($users) {
    // safe even if you delete rows inside the loop
});

Instead of paginating by offset (get the next 200 rows), chunkById() paginates by key (get rows where id > last id processed). This way, if rows get updated or deleted, it doesn't affect the process, since it's based on the row's actual identity.

Here is a clear side-by-side comparison between chunk() and chunkById() visualizing what happens when a record gets deleted:

`cursor()` - One Row at a Time

foreach (User::cursor() as $user) {
    // process each user
}

cursor() works like streaming a YouTube video. It sends one query to the database requesting all of the data, but gets each row one at a time, processes it, discards it, then moves to the next one. This way, cursor() uses up virtually zero memory from your server, no matter how significant the amount of data is. It sounds amazing at first, however, understanding when cursor() should not be used and when it can be useful is very critical.

When NOT to Use `cursor()`

Since it's one query for the entire dataset, the database connection remains busy. This matters a lot:

Slow work inside the loop: If you're doing heavy processing such as calling an external API per row, the connection stays reserved for as long as the loop takes. Let's say you have to process 2000 rows, and it takes 1 second of processing per row. That means the database connection remains completely unusable for 2000 seconds, which is about 33 minutes! If you have a large app with more than 10,000 rows to process, that's about 3 hours.
Limited database connections: During production, it is common for apps to use a limited connection pool. A cursor() loop holding open the connection for a long time can affect other parts of the app, limiting their DB connections.

When `cursor()` Can Be Useful:

cursor() can be very useful in specific situations, where you must prioritize your server's memory over speed. Here are examples where it would be a lifesaver:

Exporting massive data: Let's say you need to generate a CSV file with 500,000 rows. A standard query would crash your server due to memory overload. cursor() effortlessly processess all the rows one by one, while keeping memory usage at virtually zero.
Low traffic background jobs (queues): Running a loop in a background script (such as a Laravel Queue) late at night where not many users are around doesn't affect anything since there aren't actual users competing for DB connections.

`lazy()` - The Most Misunderstood One

User::lazy()->each(function ($user) {
    // process each user
});

Many developers share a very common misconception: lazy() behaves just like cursor(), using a single query.

In reality, lazy() uses the exact same mechanism as chunk(), processing multiple rows at a time. The only difference is on the PHP side. lazy() returns a LazyCollection, giving you access to methods such as map(), filter(), and each().

User::lazy()
    ->filter(fn ($user) => $user->isActive())
    ->each(fn ($user) => $user->sendNewsletter());

The Same Twist

Since lazy() follows the same architecture as chunk(), it comes with the same mutation issue. When updating or deleting rows, some could be skipped or processed twice. The fix to this is lazyById(), which paginates using row ID instead of offset, just like chunkById().

User::lazyById(200)->each(function ($user) {
    // safe even if you delete rows inside the loop
});

`chunk()` vs `cursor()` vs `lazy()` Summarized

Here is a clear summary of the comparison between the three methods:

Method	Query pattern	Description
`chunk()`	Many small queries	Offset-based pagination, batch by batch
`cursor()`	One query	PHP generator that streams one row at a time
`lazy()`	Many small queries	Same mechanism as `chunk()`, chainable on top

Benchmark: The Ultimate Plot Twist

To see the true differences between the three methods in action, I benchmarked them against 100,000 rows (used the same 100,000 rows for each method), measuring peak memory, number of queries, and execution time. If you want to test out this benchmark yourself or check out the setup, the full implementation is on GitHub: https://github.com/EliasAlrgeaiDev/laravel-chunk-cursor-lazy-benchmark

$startMemory = memory_get_usage();
$startTime = microtime(true);
$queryCount = 0;

DB::listen(function () use (&$queryCount) {
    $queryCount++;
});

// run the loop here

$peakMemory = memory_get_peak_usage() - $startMemory;
$executionTime = microtime(true) - $startTime;

Here is a table displaying the benchmark results:

Method	Peak memory	Query count	Execution time
`chunk()`	1.52 MB	501 queries	19.44s
`cursor()`	17.6 MB	1 query	19.86s
`lazy()`	1.52 MB	501 queries	19.39s

The Plot Twist

cursor() is supposed to be the one using the least memory, processing one row at a time, holding almost nothing in memory. But it completely caught me off guard when it used up more memory than chunk() and lazy() combined.

The cause: Laravel thinks it's doing the right thing. However, the query didn't actually hit the database. It was given to PHP's PDO (PHP data object), which by default fetches and holds the entire dataset into memory at once, then gives Laravel each row one at a time, defeating the entire purpose of using cursor().

**Note for non-MySQL devs:** This behavior only happens with MySQL databases, so if you use something else such as PostgreSQL or SQLite, you don't have to worry about any of this.

The fix is to tell PHP to stop hoarding all the data. This forces it to pull only one row at a time from the database, like how it's supposed to. To apply the fix, open config/database.php, go to the MySQL connection array, and update options to this:

// config/database.php, inside the mysql connection array
'options' => [
    PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false,
],

When I re-ran the benchmark, cursor() behaved just like expected, using the least memory:

cursor: 1.48 MB | 1 queries | 20.05s

Why use `chunk()`?

Since chunk() and lazy() performed almost exactly the same, then why does chunk() even exist if lazy() comes with nicer chainable methods while putting up the same numbers? lazy() is the latest one and the more ideal to use, however chunk() does come with 2 benefits in specific scenarios:

Batch level logic: chunk() lets you handle the entire batch as one group, like sending a notification every 200 rows processed, while lazy() only allows you to handle each row separately, so you need to write more syntax to mimic the same design.
Legacy code: lazy() was introduced in Laravel 8, so older projects heavily rely on chunk(). Continuing its use keeps things consistent.

Wrapping up

chunk(), cursor(), and lazy() all solve the same memory issue, but they have their own methods of solving it. chunk() and lazy() follow the same architectural idea, processing the dataset in small trips. The only difference is that lazy() comes with more chainable methods, while chunk() is better if you need batch-level logic or you're working with a legacy codebase. cursor() works completely different, sending one big query requesting the entire dataset, but recieving each row one at a time.

Here is a reference summarizing the differences between the 3 methods:

Situation	Use
Reading only, no chaining needed	`chunk()`
Mutating rows mid-loop	`chunkById()` or `lazyById()`
Need Collection methods (`map`, `filter`, etc.)	`lazy()`
Lowest memory usage	`cursor()`

None are wrong. It only depends on your need. Whether you prioritize saving memory, keeping old code consistent, or chainable methods, all three solve the same memory issue.

If you want to test out this benchmark yourself or check out the setup, the full implementation is on GitHub: https://github.com/EliasAlrgeaiDev/laravel-chunk-cursor-lazy-benchmark

I Made Cron and Queues Share the Work in Laravel — Here's My System

Elias Alrgeai — Sun, 26 Jul 2026 07:00:02 +0000

I used to think that cron jobs and queues are two different solutions, but now I realized they aren't competitors, they are meant to work together. I built a subscription system with automatic renewal billing called SubEngine, and found that integrating queues with cron jobs is highly efficient. Cron handles schedules. Queues handle events.

Here's how I split the work between the two, and why it remains resilient.

Cron vs Queues

Cron runs on a timer. "Every day at midnight, do X."
Queue runs on an event. "This just happened, go handle it."

Both seem like 2 different solutions to a problem, and that’s what it seems at first glance. But implementing the two together creates a highly efficient system, which I will explain why, and how I did it in SubEngine.

My System (SubEngine)

In SubEngine, every subscription with auto-renewal toggled gets a renewal attempt a day before it expires. Whether the renewal failed or succeeded, an email gets sent to the user. Here is how I split the work here:

The cron job's only task is to find who needs a renewal, and attempts
it. It doesn't send anything. Once the renewal attempt is
completed, that outcome, either success or failure, becomes an event. The event gets pushed to the queue, and the queue sends the email to the user.

Cron never touches email. Queue never touches renewal logic.
Two jobs, two responsibilities, no overlap.

Why This Split Makes a Difference

If cron sent the email directly, it must wait on your email provider to respond before moving to the next user. If the provider is slow or down, the entire renewal batch slows down or fails.

By pushing the email work to the queue, the cron remains fast and simple, while the queue can handle retries if the email fails, without ever touching renewal logic. Two systems that can fail independently without taking each other down.

A Quick Note on Scaling

This system works exceptionally on a moderate number of users, but if you've got thousands of subscriptions renewing at once, the cron begins to slow down, and your back to one process doing too much.

The fix: Don't renew inside the cron job itself. Let the cron find who needs renewing, then dispatch a job to the queue per user:

Subscription::dueTomorrow()->lazy()->each(function ($subscription) {
    ProcessRenewal::dispatch($subscription);
});

Now cron's only job is deciding who needs checking. The actual
renewal work happens in parallel, across your queue workers. Cron
gets faster, and your system scales without a rewrite.

Conclusion

Cron decides when. Queues decide what happens next. That split is what makes the system fast and reliable.

If you want to see a complete implementation, check out SubEngine. If you're solving this differently, I'd love to know your method.

Why Midnight Automated Billing Tasks Eventually Fail (And How to Fix It In Laravel 13)

Elias Alrgeai — Wed, 08 Jul 2026 14:15:51 +0000

It's 12:00 AM. Your cron job begins, like it does every night.

Except tonight, you have 40,000 active subscribers instead of 400.

The job begins charging every subscription that's due to expire that day, and in a few seconds, your database connections get maxed out. Stripe may begin returning 429 Too Many Requests errors. Then PHP times out. Now you don't know who actually got charged and who didn't.

This is the midnight cron nightmare. It's one of the most common yet avoidable flaws in subscription billing systems, and almost every self-built backend hits it at one point. Here's exactly why it happens, and how to build it correctly in Laravel 13.

The Straightforward Approach (And Why It Feels Fine at First)

Most subscription systems start out with something like this:

protected function schedule(Schedule $schedule): void
{
    $schedule->call(function () {
        Subscription::where('ends_at', '<=', now())
            ->where('status', 'active')
            ->get()
            ->each(function (Subscription $subscription) {
                $this->chargeSubscription($subscription);
            });
    })->dailyAt('00:00');
}

It's very simple, readable, and works perfectly fine in local dev with 10 test subscriptions. It'll probably survive your first few hundred users too. But this approach doesn't fail because it's wrong on day one. It fails because it's a ticking clock tied directly to your growth curve.

Why This Breaks at Scale

There are four massive issues hiding behind that simple loop:

1. The Chokepoint

If every subscription is set to renew "at expiration," and most of your users signed up around the same time (which happens naturally with growth spikes, promotions, or seasonal signups), you get a massive cluster of renewals landing on the exact same timestamp. This creates one enormous batch with zero distribution.

2. Synchronous Charging Inside a Loop

Calling a payment API synchronously inside a foreach, inside a scheduled command, means your total runtime is (number of subscriptions) × (Stripe API latency). At 40,000 subscriptions and ~300ms per charge, that's over three hours in a single PHP process. That process holds a database connection open the whole time, has a max_execution_time limit, and has no way to resume if it crashes.

3. Stripe (and your database) Will Rate-Limit You

Payment providers cap requests per second for a reason. Hit the API synchronously from one process and you'll get throttled. Throttled requests with no backoff just fail. And if you retry without idempotency, those failures can turn into duplicate charges.

4. No Idempotency = No Safety Net

If the job crashes at subscription #22,000 and you simply re-run it, you now risk re-charging the first 22,000 users who already succeeded. If you aren't tracking which renewals already ran, every retry risks double-charging your users.

None of these are edge cases. They're the default behavior of the naive cron approach once you cross a few thousand active subscriptions.

The Professional Fix: Space-out, Queue, and Track

The fix isn't a bigger server or a longer timeout. It's rethinking three things: when renewals happen, how they're executed, and what proof you keep that they happened. Here's the shape of it end to end:

1. Stagger Billing Windows — Don't Renew Everyone at Once

Instead of one giant midnight batch, spread renewal attempts across a window, and separate the renewal attempt from the actual expiration:

// Two distinct timestamps instead of one
renewal_due_at  // when we should attempt a renew
ends_at         // when access actually ends if renewal fails

Attempting renewal a day or two before ends_at rather than exactly at expiration gives you room to retry failed charges, notify the user, and smoothly kill access if the payment fails, without giving away free unpaid access or charging everyone at the same time.

2. Never Charge Synchronously Inside the Scheduler

The scheduler's only job should be to find who needs billing and dispatch work — not to do the billing itself:

protected function schedule(Schedule $schedule): void
{
    $schedule->call(function () {
        Subscription::query()
            ->where('renewal_due_at', '<=', now())
            ->where('auto_renew', true)
            ->chunkById(200, function ($subscriptions) {
                foreach ($subscriptions as $subscription) {
                    ProcessRenewal::dispatch($subscription);
                }
            });
    })->dailyAt("00:00");
}

Two important changes here:

chunkById() instead of get() — you never load 40,000 Eloquent models into memory at once.
Dispatch a queued job per subscription instead of charging inline — the scheduler's job finishes in milliseconds. The actual charging happens in the queue, where Laravel's worker pool naturally throttles concurrency, retries failed jobs, and won't take your whole app down if one charge hangs.

Notice there's no ->onQueue('billing') at the call site. Laravel 13 added Queue::route(), which lets you define the queue and connection in one place instead of repeating it every time you dispatch a job:

Queue::route(ProcessRenewal::class, connection: 'redis', queue: 'billing');

Running php artisan queue:work with a sane --tries and backoff strategy turns "one giant fragile loop" into "many small, retryable, independently-failing units of work", which is the more reliable and stable approach.

3. Make Every Renewal Attempt Idempotent

This is the piece most naive implementations skip entirely, and it's the one that actually saves you from double-charging customers on retry:

class ProcessRenewal implements ShouldQueue
{
    public function handle(): void
    {
        // Bail if this cycle already resolved — either the renewal
        // already succeeded (renewal_due_at moved forward) or it
        // already failed (auto_renew got turned off).
        if (!$this->subscription->auto_renew || $this->subscription->renewal_due_at->isFuture()) {
            return;
        }

        $result = $this->chargeCustomer($this->subscription);

        if ($result->successful()) {
            $this->subscription->update([
                'renewal_due_at' => now()->addMonth(),
                'ends_at' => now()->addMonth(),
            ]);
        } else {
            $this->subscription->update(['auto_renew' => false]);
            Mail::to($this->subscription->user)->queue(new RenewalFailed($this->subscription));
        }
    }
}

This checks real state, not a timestamp: if the renewal succeeded, renewal_due_at is already in the future. If it failed, auto_renew is already off. Either way, the job bails. If neither happened yet, it means the last attempt didn't reach an outcome, so a retry from Laravel's --tries/backoff mechanism can still fire and actually try the charge again. Pair this with treating the webhook as the real source of truth for a successful charge, and you've closed off the two biggest sources of billing bugs: duplicate charges and false-positive activations.

4. Keep Payment History, Don't Overwrite State

One more habit worth adopting: never delete or overwrite a payment record. Every attempt (successful, failed, or pending) should be its own row. When a customer emails asking "why was I charged twice" or "why did my renewal fail," you want a full audit trail, not a single status column that only remembers the most recent outcome.

Putting It Together

The shift is simple to state and easy to underestimate: stop treating billing as a loop, and start treating it as a distributed, idempotent, queue-driven sequence.

Stagger renewal windows so you're not billing everyone at once
Let the scheduler dispatch, not execute
Queue the actual charge with retries and backoff
Track idempotency so retries are always safe
Trust webhooks over synchronous responses
Keep full payment history for every attempt

None of this is exotic. Separating scheduling from doing, and attempting from confirming. But it's the difference between a billing system that quietly scales past 40,000 users and one that wakes you up at 3 AM.

A Reference Implementation

I ended up building this system in an open-source Laravel 13 backend called SubEngine — a webhook-driven subscription billing engine that implements strategic renewal timing, idempotent scheduler jobs, Stripe webhook verification, and full payment history preservation, with 31 passing tests covering the lifecycle end to end.

It's lightweight, focused on the backend billing logic that tends to break in the real world. If you're building (or rebuilding) subscription billing in Laravel, it's worth a look as a reference or a starting template.

If this saved you from a future midnight crash, a star on the repo goes a long way.