Stop Cargo Culting the levelsio Stack

Pieter Levels runs what looks like a multi-million dollar a year empire on a single PHP server with SQLite on a file. One VPS. No team. No microservices. No Redis. No “platform engineering function.” He claims hundreds of millions of requests a month off this setup. The Photo AI database hit 35.2GB and 7.27 million rows of metadata, and the thing keeps running. Respect. Genuinely.

But can we please, for the love of god, stop pretending this is a stack you should copy for your actual business.

The Levels Stack Works for Levels

Let us be honest about what is happening here. Pieter is one guy. He does not have teammates. He does not have a code review process. He does not have a customer who is going to churn because the dashboard had a bug for four hours on a Tuesday. His audience signed up to watch him build in public, and a sizeable chunk of them are buying because they like him, not because the product is bulletproof. That is a business model, and it is a real one. It is just not yours.

When you are levelsio and you are serving an audience that is, frankly, fine with a bit of jank, the PHP-on-a-VPS stack is incredible. It is fast to copy paste from your other ten projects. A single-process PHP server can beautifully use SQLite on a file because there is one writer anyway and nobody else is putting data into your webapp. It is cheap. It is enough for 90% of the hobby projects out there. I genuinely agree with all of that.

That is the steelman. Honestly, if you are shipping something on a Saturday by yourself and you want it live by Sunday, do this. Stop reading and go ship. PHP plus SQLite plus a $5 droplet will get you further than most “modern” stacks will, and you will not have spent six hours configuring a Kubernetes cluster for an app with seventeen users.

But that is what it is. A weekend thing. Solo. Fast and dirty. Nobody else trying to read the code, because there is no team. Nobody depending on it, because the worst case if it falls over is a Twitter post about how you are “fixing it now.”

Where It Falls Apart

The minute you have a second person on the team, this stack starts to bleed.

SQLite is a single-writer database. Pieter himself has said publicly that searching 7.5 million records is noticeably slower than searching 100k. That is fine when you are the only person looking at the bottleneck and you can just… not search 7.5 million records. It is not fine when you have customers hammering the API with queries you cannot predict, and their dashboard takes 8 seconds to load because your database is locked behind one writer and a query plan that nobody on your team understands well enough to fix.

PHP without a real testing culture, on a single VPS, with SQLite, is also basically un-CI-able in a sane way. You cannot spin up parallel test workers writing to the same SQLite file without lock contention. You cannot do blue-green deploys against a database that lives on the same disk as the app process. You cannot horizontally scale because the database IS the file system of one specific server. The whole stack assumes one machine, one process, one writer, one human in charge. Add literally anything to that equation and the abstractions start leaking.

And then there is the part nobody likes to talk about. Your SQLite file is on the disk of one VPS. That VPS goes down, your business goes down. Hetzner has a bad day, your business has a bad day. You can Litestream the file to S3, sure. You can use Turso or D1 or LibSQL to paper over the replication problem. Cool. Now you are running a distributed database and you are doing it because you wanted to keep things simple. Read that sentence again.

The SQLite Renaissance Is Real and Also Not the Point

I know. Turso. Cloudflare D1. LibSQL. Litestream. The 2026 SQLite renaissance is genuinely cool and I am rooting for it. A bunch of smart people are working on the limitations — replication, multi-writer, fan-out reads — and a lot of them are landing.

But notice what is happening. Every one of those tools exists because the levelsio stack does not actually scale past one machine. The whole reason these projects have momentum is that the “just put SQLite on a file” pitch breaks the moment you need two of anything. You cannot use the renaissance as evidence the original stack was right. The renaissance IS the patch.

And once you have layered Turso plus Litestream plus a CDN plus a queue plus whatever else, you do not have a simple stack anymore. You have Postgres with extra steps, written by a different vendor, with worse tooling. You could have just used Postgres.

The Survivorship Bias Problem

Every time levelsio posts a screenshot of his htop, ten thousand people in his replies decide they are going to build their B2B SaaS on the same stack. This is the cargo cult I am annoyed at. Not Pieter. Pieter is doing his thing.

The cargo cult is the founder who watches the videos, copies the architecture, ships a customer-facing app, gets ten paying customers, and then completely melts down when one of them needs a feature that requires a second writer. Or when the VPS runs out of disk. Or when their cofounder joins and immediately asks “wait, where are the migrations?” Or when the database hits 30GB and a query that used to take 50ms now takes 4 seconds and they have no idea why because they have never had to read a query plan in their life.

Levels works because of Levels. The audience, the brand, the speed of iteration, the willingness of his customers to accept rough edges. Strip those away and the stack does not magically carry your B2B accounting tool to a $10M ARR. You are not buying his outcome by buying his architecture. You are buying his architecture and getting your own outcome, which is going to look very different because you do not have his audience.

What to Actually Use

I am not here to sell you on a fifteen-service architecture. Do not do that either.

For a real product, with real customers, with even one teammate, the boring answer is still the right answer. A monolith. Postgres. Deploy it on Fly or Render or a couple of EC2 instances behind a load balancer. Run migrations. Have a CI pipeline that actually runs your tests in parallel without fighting a database lock. You will spend maybe one extra weekend setting it up and you will save yourself two years of pain.

If you are solo, on a weekend, and the project is for fun or for a tiny audience that loves you, sure. PHP and SQLite. Ship it tonight. I am not going to be mad at you. I might even use it.

But the moment a customer is paying you, or a teammate is writing code with you, or your data is anything you cannot afford to lose for a few hours, you are not in levelsio territory anymore. You are running a business. Pick the stack for the business you are running, not the one whose YouTube videos you watched last week.

The stack is not the moat. It never was.