A job failed in production at 2am. Memory limit exhausted. Process killed. The Artisan command exported orders. It worked fine in development with 500 rows. In production with 800,000 rows, it consumed all available PHP memory and died. The fix everyone reaches for: increase memory_limit. That's the wrong answer. The right answer is understanding which of Laravel's four large-dataset tools is correct for the specific operation. Here's what I learned from measuring all four on 1,000,000 rows. Order::all() with 100,000 rows used 284MB of memory. Extrapolated to 1,000,000 rows: 2.84GB. The default PHP memory limit is 256MB. The math ends in a fatal error before the loop even starts. cursor() used 8MB on 1,000,000 rows. The same 8MB. Constant. It holds the database connection open and yields one Eloquent model at a time. Only one object in memory at any moment. The cursor() gotcha I hit immediately: you can't run other queries on the same connection while the cursor is open. Customer::find() inside the foreach loop threw PDOException: Cannot execute queries while other unbuffered queries are active. The fix: eager load with() before the loop, not inside it. The chunk() bug I hit later — the dangerous one. I was processing a column I was also filtering on. Chunk 1 queries WHERE processed = false LIMIT 100 OFFSET 0, updates those 100 rows to processed = true. Chunk 2 queries WHERE processed = false LIMIT 100 OFFSET 100. But those 100 rows are now gone from the result set. OFFSET 100 skips the next 100 unprocessed rows. The command completed without errors. About half the rows were never processed. chunkById() fixed it. ID-based pagination doesn't depend on the result set order. Each chunk queries WHERE processed = false AND id > {lastId}. Modifying 'processed' doesn't affect which rows appear in the next chunk. The numbers from the measurement: cursor(): 8MB, constant regardless of row count lazy(): 9MB, with Collection methods chainable chunk(500): 12MB, safe for writes chunkById(500): 12MB, safe for writes AND for modifying the filtered columns The time differences are smaller than expected. Memory is the only dimension that matters at scale. The rule I use now: if I don't know the size of the result set, I don't use get(). Correct defaults for Artisan commands and background jobs: chunkById() for writes, lazy() for reads, get() only for queries with an explicit limit(). Full post with all gotchas, the complete chunk() skip bug explanation, and the memory-safe Artisan command template on the article. #Laravel #LaravelDeveloper #PHPDeveloper #PHPPerformance #DatabaseOptimization #BackendDevelopment #PHPFramework #SoftwareEngineering #LaravelTips #WebDevelopment #PHPCommunity #BackendEngineering #TechBlog #MySQL #EloquentORM #PHPDevelopment #ServerPerformance #Laravel13 #CodeOptimization #ApnaHive sadiqueali.medium.com/larave…

Laravel only needs one thing from you. That you embrace it. Kiss it even. Delegate as much work to the framework as possible. Don't reinvent the wheel. For instance, are you feeling like creating a src directory? Don't. The app directory is what you're looking for. ✓ Feeling like creating modules? Don't. Subfolders inside the default structure is what you're looking for. Keep it familiar for your coworkers to ensure maximum productivity. ✓ Feeling like coding a feature from scratch? Don't. Laravel probably offers it already. And third party packages are already there too. ✓ Be the kind of developer who delivers and leaves a clean legacy.

Great read about importing a huge amount of data 👍 Thanks @JonPurvis_ jonathanpurvis.co.uk/importi…