Introducing Litebase

Today, I’m extremely excited to introduce Litebase. An MIT-licensed database that combines the simplicity of SQLite with the power of distributed storage. What began as a simple idea has grown into something real, a project designed to make databases more accessible, scalable, and cost-efficient, without the complexity that often comes with modern cloud systems.

I just walked off the stage at Laracon US, where I introduced Litebase to my friends and peers in the Laravel community.

Nearly six years ago, I was sitting in the audience at Laracon in Times Square, New York, when I watched Taylor Otwell unveil Laravel Vapor. It was a game-changing moment, a tool that made it incredibly easy to deploy Laravel apps to the cloud, and it inspired me to explore countless application ideas.

But along the way, I kept hitting the same friction point: spinning up a simple, cost-efficient, and robust database. Even with modern tooling, I often found myself battling complexity, overpaying for underused resources, or giving up too much control.

That pain point became the seed for what eventually grew into Litebase. At first, I naively tried to scratch my own itch by running SQLite on NFS. I figured: why not just plug SQLite into a shared filesystem and call it a day?

Long story short, that idea unraveled fast. I quickly ran into the limitations of using SQLite on distributed file systems that don’t support memory-mapped files and require multiple network round trips just to lock and unlock the database. Performance tanked. Reliability suffered. And I realized this was’t going to be as simple as I hoped.

As you read along, you’ll see I’ve made it to the other side. I’ve learned a lot more about databases than I ever expected, including more than a few ways to corrupt one! But that journey gave me the confidence to finally share this crazy idea.

Getting to unveil Litebase for the first time at Laracon truly felt like a full-circle moment.

The dream

For years, I’ve dreamed of doing something as simple as this:

shell

$ litebase import ./app.sqlite

And instantly having access to that database over HTTP.

http

POST /query HTTP/1.1
Content-Type: application/json
{
  "query": "SELECT * FROM users WHERE id = ?",
  "params": [1]
}

Are we fully there today? Not quite. But I’m getting closer every day, and it finally feels like the right time to put my cards on the table. It’s time to ship.

The dare

I’ll admit — I sat on this idea for too long. And yes, I’m well aware that others have started shipping their own versions of “SQLite-as-a-Service.” So why not just use one of those?

Two reasons:

I think I had the idea first, and just because someone ships before you doesn’t mean you shouldn’t ship at all. Being late to the game is still better than never playing.
Once I realized this might actually be possible, I dared myself to go deeper. Serving SQLite over HTTP wasn’t enough. I knew I’d need to build an actual remote database management system around SQLite. Even if I was reinventing the wheel, I figured the process alone would teach me something valuable.

So down the rabbit hole I went. Learning how to write Go, dabbling in C to work with SQLite’s C APIs and diving into a bunch of topics related to databases and distributed systems.

The database

Yes — I’m building a database.

It’s not just SQLite, though. Calling it “SQLite Server” or “SQLite over HTTP” doesn’t really capture what Litebase is, or what developers should expect when they use it. You won’t get raw access to every SQLite C API. You won’t be fiddling with every PRAGMA trying to squeeze out the perfect config. Litebase is opinionated. It takes the power of SQLite and wraps it in a distributed system that’s designed to be simple, scalable, and cloud-native out of the box. Here are the key components I’m building today:

Litebase Server

It all starts with a single Go binary that embeds SQLite and coordinates read and write access to your databases. Litebase Server can run standalone or as part of a cluster, letting you scale reads with replicas and access databases over HTTP. It’s lightweight, fast, and easy to deploy, just run the binary and you’re live.

Eventually, the long-term goal is to deliver a great developer experience across the board from local development to single-instance deployments, to multiple nodes with smooth operation in Docker or Kubernetes.

Litebase Distributed File Storage

Litebase includes a distributed file storage layer that tiers data across different storage classes, from fast local disk to durable object storage. At the core of this system is a new backend model called the Structured Log. It transforms a traditional SQLite file into a multi-version log-structured merge tree, preserving the familiar SQLite format while enabling versioning, durability, and operations on the database without rigid locking constraints.

I believe these enhancements make Litebase a great fit for read-heavy applications that need to scale, teams looking to save on storage costs, and platforms managing hundreds or even thousands of databases without the overhead of manual storage allocation.

Litebase Query Transfer Protocol

Accessing a database over HTTP with JSON is convenient, but to unlock the next level of performance, I needed something faster.

That’s why I built LQTP, a custom binary protocol layered over HTTP, designed to minimize network bandwidth and reduce data marshalling overhead. It enables low-latency communication for SQL queries, with data transferred in frames. This not only allows large result sets to be streamed efficiently, but also gives clients a way to batch concurrent requests and amortize the cost of network round trips.

Continuing releasing documentation about how Litebase works
Build the CLI and add a release process
Release PHP and Laravel SDKs

This is just the beginning — if you’re curious, excited, or even skeptical, I’d love to hear from you.

Join the conversation on

GitHub Discussions