Triplit 1.0 is coming on March 11th with 10-100X the performance

We started working on Triplit to build a tool that would help us write low latency collaborative applications with minimal code. We imagined something like Firebase or Supabase (products we’ve greatly enjoyed using) but designed specifically for the types of applications we found ourselves making over and over again. Every app we built as a team had the same requirements: work on the web, be highly responsive to user interactions, and sync across users' devices. Most apps now have these as goals, if not requirements, so we were surprised at how hard it was to achieve this user experience with the tools available.

We had an interesting idea of how to solve this: what if instead of handling caching on the client as a special case, we used a distributed database that could run on both the device and the server and synced data between the two. Instead of writing a bunch of code to manage a cache yourself (a famously hard problem), a developer could just write database queries and mutations directly in their client code. These operations would run directly on the client with zero network latency. They would eventually sync with the server and other devices. As a bonus, the client would work offline by default.

The recipe for Triplit

First, we needed a query engine that could work on both client and server. We originally thought we could use something like SQLite which can now run in the browser thanks to Web Assembly; however, SQLite, despite being awesome in many ways, is not a great fit for browser applications. For one, SQLite run queries synchronously. It will cause your UI to freeze during long running queries unless you run it in a Web Worker. Additionally, SQLite (and most query engines) don’t have the ability to keep a query up to date as data changes, i.e. “live” queries so you have to resort to repeatedly refreshing the query from scratch which is inefficient or manually updating the query as data changes which is quite complex especially for relational queries. On top of that there is unavoidable overhead of converting values like strings between the C code for SQLite and JS environment for your application.

Second, we had to build a sync engine to allow updates to the data on the server to flow to the clients and vice versa, all while guaranteeing that all clients/users see a consistent view of the data. It would need to send the minimal diff for each client mutation or query update, handle rollbacks for unauthorized or malformed changes, and respect authorization rules.

Finally, we needed to be able to durably store data anywhere Javascript code runs. That means, in the browser, it should run in-memory or with IndexedDB and, on the server, it could save to the local filesystem using something like LevelDB, SQLite, etc or even in edge environments like Cloudflare’s Durable Objects.

At the risk of a few thousand more words, we also wanted Triplit to have:

Schemas, defined in code, for data integrity…
…which could also enable first-class Typescript support
Support for relational data models
The ability to work fully offline (e.g. powering a PWA)

Triplit today

We’re now two years into developing Triplit and in 2024 we invited developers to use it in their own applications. With the guidance of these early adopters, we iterated on Triplit’s design and built tools to make it even easier to use. We made framework bindings for most of the popular frameworks: React, Vue, Svelte, Angular and React Native. We released a CLI tool to make it simple to run a Triplit server locally for development or safely push changes to your schema in production. We created a UI to visually explore and manage the data stored in Triplit. And we launched Triplit Cloud to allow developers to deploy a Triplit server without managing servers themselves. And for the folks who wanted to self-host, we published a Docker image of the Triplit sync server. Hundreds of developers have signed up and deployed projects to our Cloud and many more have downloaded and run Triplit on their own hardware.

Each step of the way, we’ve been guided by the feedback of our growing developer community. One piece of feedback has stood out the most and it goes roughly like: “hey I love using Triplit but I want it to be faster.” We’ve made many incremental improvements to Triplit’s performance but often hinted at a new version in the future that wouldn’t have these performance limitations. Well the wait is nearly over. We’re excited to share that 1.0 is coming on March 11 with a new engine that’s way faster, 100X faster in some cases.

The big 1.0

Triplit 1.0 should be fast enough for most applications and scale to thousands of users. Our focus going forward is to continuously push the ceiling of what applications are possible with Triplit. We have to give thanks again to our early developers for helping shape the API. We don’t anticipate any breaking changes in the near future, instead you can look forward new APIs for aggregations, new data types, and better tooling for managing your Triplit deployments later this year.

If you haven't tried Triplit yet, you can get started today and then experience the new improvements in March!