Most engineering teams treat the three-tier architecture as a default setting rather than a choice. That is precisely why Johannes Schickling's journey matters. He did not just swap one database for another; he questioned the entire premise of where computation and state should live. Moving from Prisma to building Overtone, a music curation app, he embraced client-side event sourcing with SQLite as the engine. The result is a system that feels instant because it is local, and it stays synchronized because the event log is the source of truth. This is not nostalgia for simpler times. It is a deliberate rejection of the assumption that the server must be the brain and the client merely a screen. For readers still debugging network latency in their own apps, this story offers a concrete alternative worth studying.
The trade-offs Schickling surfaces between event sourcing and CRDTs are where the practical value lives. Event sourcing gives you a full history and replayability, but it demands discipline. CRDTs offer automatic merging without a central coordinator, yet they can bloat state and complicate reasoning. Schickling's choice to lean on SQLite on the client is telling because it signals a preference for durability and query power over the eventual-consistency free-for-all that many local-first tools tolerate. If you have ever tried to build offline-first features, you know the pain of reconciling divergent branches. His approach suggests a middle path: keep the event log authoritative, let the client own the database, and treat the server as a sync relay rather than a god. This aligns with a broader theme we have been tracking, such as how Scale AWS Server Deployments Effortlessly with Stateless Model Context Protocol reduces server-side session overhead, or how Bridging Retrieval and Action: A New Approach to AI Tasks pushes logic toward the edge. The common thread is that the network is no longer the bottleneck we should be designing around.
Our honest take is that most teams are over-indexing on server-centric complexity because it is familiar. The three-tier stack is not wrong, but it is not sacred. Schickling's work is a reminder that the client can be a first-class citizen, not just a thin shell. If you are evaluating whether to adopt this model, start with a small, non-critical app. Measure the developer experience, not just the runtime performance. The real win is not that SQLite runs in the browser. It is that you can ship features that work offline, sync when ready, and never lose a user's edit. That is a user outcome, not a technical footnote.
The open question we are left with is whether this approach scales beyond solo developers or small teams. Overtone is one person's product, and that is fine. But for a team used to shared Postgres schemas, moving to per-user SQLite databases requires rethinking migrations, backups, and conflict resolution. We would tell a reader asking about this: do not wait for a framework to solve this for you. Read Schickling's code, run it, and then decide if the trade-off between event sourcing and CRDTs matches your data model. The specific detail to watch is how he handles schema evolution across distributed clients. If he solves that cleanly, the local-first movement takes a significant step forward. If not, the idea remains a promising experiment rather than a production playbook.