PHP’s 100-Million-Row Challenge Gives Devs 2 Weeks to Prove the Language Isn’t Slow
Honestly, someone said “PHP is fast now” and a man woke up and chose violence — a 7GB CSV, a $6 server, and two weeks to parse it all.
100,000,000 rows. 2 vCPUs. 1.5GB RAM. No JIT. No FFI. Just PHP and spite.
Brent Roose — the guy behind the Tempest PHP framework — just launched a community speed challenge that’s basically “The Fast and the Furious but with associative arrays.” It runs from Feb 24 to March 15, 2026, and it’s already getting pull requests.


🧩 Dumb Mode Dictionary
| Term | Translation |
|---|---|
| 1BRC | The One Billion Row Challenge — a Java speed contest from 2024 that started this whole genre |
| JIT | Just-In-Time compilation — PHP 8’s turbo button that makes code run faster (disabled here, because pain) |
| FFI | Foreign Function Interface — lets PHP call C code directly (also banned, no cheating) |
| CSV | Comma-Separated Values — a spreadsheet pretending to be a database |
| Memory-mapped files | Reading files by mapping them directly into RAM instead of loading chunks. Fast but tricky |
| Elephpant | A stuffed PHP elephant mascot. Devs will literally fight for these |
📖 The Backstory: From 5 Days to 30 Seconds
Brent Roose had a PHP script that took 5 days to process 11 million rows. Through a series of optimizations — cursor-based pagination, batched inserts, moving calculations out of the database — he got it under 30 seconds.
That experience broke something in him. He thought: “What if I made other people suffer through this too?”
So he built the 100-Million-Row Challenge. Parse a massive CSV of page visit data (URLs + timestamps), aggregate visits by path and date, spit out pretty-printed JSON. Simple problem. Monstrous dataset.
The challenge is inspired by Gunnar Morling’s 1 Billion Row Challenge from 2024, which had Java devs getting aggregate times down to 1.5 seconds using SIMD, memory-mapped files, and custom hash tables. PHP’s version scales down to 100M rows but strips away the escape hatches — no JIT, no FFI, no calling C from the shadows.
⚙️ The Rules: Deliberately Cruel
- You write a
Parserclass in PHP. That’s it. - Input: ~7GB CSV file with 100 million rows of page visits
- Output: JSON with visits aggregated by URL path and date, sorted chronologically
- JIT disabled — no compiler magic
- FFI banned — no sneaking in C libraries
- Benchmark server: Premium Intel DigitalOcean Droplet (2 vCPUs, 1.5GB RAM)
- Available extensions: bcmath, curl, json, mbstring, pdo, redis, sqlite3, and a few others
- Submit via pull request. Copying = disqualification.
- Deadline: March 15, 2026, 11:59 PM CET
Honestly, the 1.5GB RAM cap is the real villain here. That’s not enough to hold the whole file in memory. You have to stream it, chunk it, or get creative.
🏆 What You Win (Yes, Elephpants)
| Place | Prize |
|---|---|
| PhpStorm Elephpant + Tideways Elephpant + 1-year JetBrains all-products license + 3-month AI Ultimate + 1-year Tideways Team | |
| Tideways Elephpant + 1-year JetBrains all-products license + 1-year Tideways Team | |
| 1-year JetBrains all-products license + 1-year Tideways Team |
The Elephpants alone would justify the entry. Those things are collector’s items — people trade them like Pokémon cards at PHP conferences.

🗣️ What the HN Crowd Is Saying
- “This is less about PHP, and more about optimizing how you’re using the database” — okay but the challenge has no database, it’s raw file parsing
- Multiple devs asking about consistent random seeds for local testing (the generated dataset needs to match)
- Some skepticism about whether this is just microbenchmarking — but that’s… literally the point?
- Several people reminiscing about the original 1BRC and how it spawned implementations in Go, Rust, C, Python, even awk
- General surprise that PHP can do anything fast (as is tradition)
📊 The 1BRC Legacy: Why These Challenges Matter
The original 1 Billion Row Challenge results showed that the same problem could be solved in wildly different times:
| Language | Winning Time | Key Technique |
|---|---|---|
| Java | ~1.5 seconds | SIMD + memory-mapped files + custom hash tables |
| Go | ~3.4 seconds | Parallel chunking + integer-only temp parsing |
| C | ~1.7 seconds | mmap + unrolled loops + branchless parsing |
| Rust | ~1.8 seconds | Rayon parallelism + zero-copy parsing |
| Python | Minutes | Being Python |
PHP sits somewhere in a weird middle ground. It’s interpreted but has an opcode cache. It’s single-threaded but can fork. It can’t do SIMD without FFI. The constraints make this genuinely interesting — not “can you make PHP as fast as C?” but “how fast can PHP actually go when you stop writing WordPress plugins?”
Cool. PHP devs are speed-running CSV parsing. Now What the Hell Do We Do? ᕕ( ᐛ )ᕗ

💰 1. Enter the Challenge and Get Known
If you write PHP, this is free marketing. Top entries get visibility across the PHP community, HN, and Twitter. Even placing outside the top 3 gets your GitHub profile in front of hiring managers and framework maintainers.
You have until March 15. Submit a PR with your Parser class. The leaderboard is public.
Example: A backend dev in Lagos, Nigeria entered the 1BRC Java challenge in 2024, placed top 20, wrote a blog post about their approach, and got 3 contract offers within a month from companies who saw the writeup.
Timeline: 1-2 weeks of optimization work → PR submitted → results posted publicly by mid-March
🔧 2. Build a PHP Performance Audit Service
Okay but seriously — most PHP codebases are running on vibes and foreach loops. If you can optimize a 7GB CSV parse on 1.5GB RAM, you can absolutely audit someone’s Laravel app that takes 8 seconds to load a dashboard.
Package this as a fixed-price “PHP Performance Audit” — review their slowest endpoints, profile with Tideways or Xdebug, deliver a report with specific fixes.
Example: A freelancer in Krakow, Poland started offering “Laravel Speed Audits” on Upwork after the 1BRC trend, priced at $500/audit. Got 4 clients in the first month, with two converting to retainers at $2K/month for ongoing optimization work.
Timeline: 1 week to build a portfolio piece from the challenge → list service on freelance platforms → first client within 2-3 weeks
📝 3. Write the 'How I Optimized' Blog Post
Every single winner and top-placer in the original 1BRC who wrote a detailed breakdown got massive traffic. Ben Hoyt’s Go walkthrough (“from 1m45s to 3.4s in nine solutions”) is still getting shared two years later.
Write about your approach. What worked, what didn’t, where the bottlenecks were. These posts get bookmarked by engineering teams and shared in Slack channels. They’re evergreen content.
Example: A dev in São Paulo, Brazil wrote a deep-dive on their 1BRC Rust solution, posted it to HN, got 47K pageviews in a week, and parlayed the traffic into a paid newsletter about systems programming that now has 1,200 subscribers at $8/month.
Timeline: Enter challenge now → write blog post mid-March → publish when results drop → traffic spike within days
💼 4. Create a 'PHP Optimization Patterns' Course
There’s a gap in the PHP education market between “here’s how to use Laravel” and “here’s how to make PHP not embarrass itself at scale.” This challenge is generating real optimization patterns — streaming parsers, memory-efficient aggregation, chunk processing — that apply to any PHP codebase.
Record a course. Sell it on your own site or Udemy. Target the “my PHP app is slow and I don’t know why” crowd (which is… large).
Example: A senior PHP dev in Bucharest, Romania recorded a 4-hour course on PHP performance patterns after contributing to Tempest PHP, sold it for $49 on Gumroad, and made $6,800 in the first quarter mostly from organic Twitter traffic.
Timeline: Participate in challenge (Feb-March) → outline course from lessons learned → record and launch by April → passive income from there
🛠️ Follow-Up Actions
| Step | Action | Tool/Link |
|---|---|---|
| 1 | Fork the repo and start experimenting | GitHub Repo |
| 2 | Generate the test dataset locally | Follow repo README setup instructions |
| 3 | Profile your solution | Tideways, Xdebug, or microtime(true) |
| 4 | Submit PR before March 15 | Standard GitHub PR workflow |
| 5 | Write your optimization breakdown | Dev.to, personal blog, or HN Show post |
| 6 | Follow @brendt_gd for leaderboard updates | Twitter/X |
Quick Hits
| Want to… | Do this |
|---|---|
Fork the repo, write your Parser class, submit a PR |
|
| Read the 1BRC results for optimization inspiration | |
| Generate a smaller dataset (1M rows), validate output, then scale up | |
| Check the HN thread and repo issues | |
| Visit stitcher.io — Brent’s blog with years of PHP content |
Honestly, if PHP can parse 100 million rows on a $6 server before your React app finishes its first hydration pass… maybe we’ve been making fun of the wrong language.
!