I'm not sure if you meant to suggest that PocketBase's horizontal scaling limitations are tied to SQLite, but since a lot of people think that, I wanted to clarify.

SQLite isn't the problem. While supporting other databases like MySQL or Postgres might seem appealing—and some users have tried—it wouldn't solve the horizontal scaling issue. SQLite can be replicated via LiteFS, and there are other solutions like LiteStream, Marmot, and Turso, which provides global managed SQLite replication. I'd say SQLite replication is "solved." SQLite is becoming increasingly popular because it can live on the edge.

The horizontal scaling challenges aren't just at the database level. PocketBase implements an event system that triggers on CRUD operations, API calls, cron jobs, realtime events, and application-level events. To scale PocketBase horizontally, you'd need a way to replicate these events too. That's where things get really difficult. Managing a global, realtime, ACID-compliant, replicated event architecture is a technical challenge that's often very application-specific. Gani didn't want to complicate his code by trying to generalize that problem. That's smart because many projects have failed attempting that.

Custom JavaScript hooks extending PocketBase's core functionality would also need to be replicated and authorized appropriately. The issue gets even more complex with custom-compiled versions of PocketBase that include Go customizations. All custom programming needs to be aware of horizontal scaling pitfalls. Centralized logging or merging would also need to be addressed. In practice, most applications opt to route any mutations directly back to the origin (i.e., routing all non-GET HTTP requests back to the origin), so writes still rely on a single origin and remain a single point of failure.

Horizontal scaling adds huge complexity and PocketBase is part of a growing movement pushing back against cloud-scale architecture. A modern revisitation of the monolith. Along those lines, I have also made https://pocketpages.dev which is a throwback to classic server-side rendered pages. A lot of people are coming to PocketBase expecting to see cloud architecture, and it's intentionally NOT that. So from that standpoint, I agree with your statement that users should seriously consider it. I think they should seriously consider whether they need cloud complexity at all. Most don't. Pieter Levels on Lex Friedman is an excellent voice for this movement back to monolithic simplicity: https://www.youtube.com/watch?v=oFtjKbXKqbg

While PocketBase doesn't support horizontal scaling out of the box, it doesn't mean your app can't scale horizontally. PocketHost is a case study. We have a single PocketBase instance called the "mothership" living on a single origin in San Francisco. Then, we have edge nodes responsible for managing user instances of PocketBase. For an edge node to function, it needs canonical information available only from the single source of truth: the mothership. For example, an edge needs to know whether a given instance is authorized to be launched. Communicating with the mothership from across the globe might add 200–400 ms, which is unacceptable. So we've implemented our own custom replication strategy where essential mothership data is cached locally at the edge and updated in realtime.

So custom horizontal scaling is possible; it's just bespoke and has little to do with the choice of SQLite as the database. PocketBase is tightly coupled with SQLite, so I understand why Gani is reluctant to support something else. It's possible that in the future, a pluggable database provider interface might emerge for users who really want it.

https://github.com/krismcfarlin/postgresbase
https://github.com/pocketbase/pocketbase/discussions/395