I put "SQLite maximalist" in my GitHub bio and nobody has ever asked me to explain it. Which is fine. But I think about it more than a person probably should. It started as a joke about a database preference and turned into something that feels more like a worldview. Most problems are smaller than you think they are, and the solution you reach for first is almost always more complicated than the problem requires. SQLite is just a file. No server. Doesn't need one. For the overwhelming majority of applications that humans actually need to build, it is completely sufficient and often outright better than the alternative. But developers keep spinning up Postgres instances for todo apps and internal tools with twelve users because that's what serious projects use. That's what scales. Scales to what, exactly.
The maximalism part has nothing to do with SQLite specifically. It's about the discipline of resisting complexity that hasn't been earned yet. Every abstraction layer, every additional service, every "we might need this later" decision is a bet against your future self. Sometimes those bets pay off. Mostly they just make the codebase harder to reason about and the local dev setup a small nightmare. SQLite forces the question in a way most tools don't: do you need more than this? More often than I expected when I started asking, the answer is no.
Choosing a tool that fits in a single file has real consequences. It travels with the project. Backs up with a copy command. Works on a Raspberry Pi and works on a server with 64 cores and doesn't care either way. No daemon to babysit, no connection pool to tune, no authentication layer to configure before you can write your first query. Open a file, start working. Someone made those decisions deliberately, and I respect them the same way I respect any well-considered constraint. The build step you added because modern projects have build steps. The framework you reached for because it's what everyone uses. The microservice you spun out because the monolith felt embarrassing. None of those decisions are inherently wrong, but none of them are free either. Complexity has a carrying cost, paid slowly, in small increments, usually by future you at the worst possible time.
SQLite works. A static site works. PHP works. A shell script works. A lot of infrastructure exists primarily to make developers feel like they're doing something serious rather than to serve any need the project has. "Works" is the goal, and the simple tool gets you there without the carrying cost.
Somewhere along the way, choosing the simple tool became the contrarian position. I find that more interesting than anything the complicated tools have to offer.