PocketBase: A Lightweight Alternative for Your Next Project

Recently, an article was published about Firebase alternatives, and readers were quick to point out a very important project that was left out: PocketBase.

After trying it out, it was immediately impressive. The home page features a creative proximity hover effect where a pair of eyes follows the cursor, which is a nice touch. At first glance, it looks very similar to Supabase, offering features like a real-time relational database, authentication, and file storage. It's built entirely with open-source software, unlike Firebase, which relies on proprietary Google technology.

While it resembles other backend-as-a-service solutions on the surface, it's quite different under the hood and has the potential to be the ultimate backend for side projects.

PocketBase vs. Supabase: A Closer Look

The first thing you'll notice is that it's written in the Go programming language, as opposed to TypeScript for Supabase. While this might seem superficial, applications built with Go do tend to be faster. It also uses Svelte for its admin UI, while Supabase uses React and Firebase uses Angular. This is more of a fun fact than a critical difference, but interesting nonetheless.

For client-side SDKs, it supports JavaScript and Dart, making it usable across web, desktop, and mobile platforms.

The Database: Embedded SQLite

What's truly interesting about PocketBase, however, is its database. Instead of using a traditional database like PostgreSQL or MySQL, it directly embeds SQLite into the executable. It runs in WAL (Write-Ahead Logging) mode.

The initial thought might be that SQLite isn't suitable for production, but that's a common misconception. SQLite is an underappreciated option for numerous small to medium-sized projects. Surprisingly, in WAL mode, it can outperform other relational databases, especially in read-heavy applications. It will likely work perfectly fine for your side project.

But in the off chance of success, you might be wondering: does PocketBase scale?

Understanding Scalability

Because the database is embedded into the runtime itself, it can only scale vertically. This differs from NoSQL databases like Firestore, which use sharding to scale horizontally across a virtually infinite number of machines.

When scaling vertically, the only way to handle more traffic is to use a bigger computer. As the application grows, you'll need to add more CPU and more RAM, but there's a limit. For instance, one of the largest instances available on AWS offers 128 CPU cores and about 2 terabytes of RAM, with a cost comparable to a Bay Area studio apartment.

In any case, vertical scaling will work for the vast majority of applications. PocketBase can easily handle tens of thousands of concurrent real-time connections on a single, inexpensive virtual machine.

Deployment and Self-Hosting

This brings us to the next point: PocketBase is entirely self-hostable. In fact, you have to self-host it. This contrasts with Supabase, where many users opt for the fully managed service. Supabase has also been criticized for being difficult to self-host, with a Docker Compose setup involving over 6+ different services to manage.

What's unique about PocketBase is that it compiles down to a single executable file, which makes deployment incredibly simple. Another important difference is how you handle backend code. You can extend the framework directly with Go, and that code will be compiled into the executable right alongside your database. In other words, you build a monolith, as opposed to managing a collection of microservices that run on edge functions.

In fact, a monolithic architecture can often be faster than the edge when significant data fetching is involved.

Final Thoughts

The bottom line is that PocketBase serves as a lightweight alternative to Supabase, which in turn is an open-source alternative to Firebase. Ultimately, these platforms provide an alternative to building your own backend from scratch.