Show HN: Triplit – Open-source syncing database that runs on server and client

Hi Triplit's team,

Congrats on the launch and thanks for the awesome product! I've been using Triplit in one of my projects [1], and it do work as expected. In my self-promotion on Reddit [2], I posted about Triplit as well:

> I think Triplit is a nice database and works as expected. It's data model fits well with what I have in mind (more decentralized/P2P instead of having a single centralized database as the source of truth), but there are 2 areas I find lacking:

> - Server side/self-hosted: Triplit server requires a token for authentication. Triplit's documentation has a section about how to start the server without explicitly showing how to generate the token, which is mildly inconvenient. Therefore, on self-hosting the server, I opted for using their CLI command dev since the command has the token generation that I needed. I know it is not a good security practice as when the command is used as a system service, the token will be logged in plain text, but I have a bigger problem when someone can access that anyway.

> - Query language: I find their custom query DSL not as expressive as a full-fledged query language (lacking UNIQUE and COUNT like SQL is on the top of my mind). You'll have to do a bit of data aggregating yourself.

Recently, I found Evolu [3], which is quite similar to your project in terms of scope and functionalities as well. From a quick skim of their documentation, I think the differences are:

- Triplit have `.subscribe()`, while Evolu don't

- Evolu's querying is more familiar/advanced (typed SQL via Kysely)

- In the browser, Evolu seems to use SQLite on top of OPFS, while Triplit uses IndexedDB

I think there are more intricacies on the way Triplit differs from Evolu, so can you enlighten me on that?

Really appreciate your comment! Thanks!

- [1]: https://github.com/thanhnguyen2187/cryptaa

- [2]: https://www.reddit.com/r/sveltejs/comments/1dndpj8/cryptaa_a...

- [3]: https://www.evolu.dev/docs

Related question: when you're using databases with great offline sync protocols like this, how do you do schema evolution of your DB, especially in the face of different client versions that you cannot upgrade in lockstep?

My context here is having worked in the past on a mobile health app, and recalling all the pain we had around this problem.

I don't understand in what apps it's acceptable for the client to be able to write to the database directly. Or how you can get away without any backend logic.

I have the same questions about Supabase and Firestore so it seems like I'm missing something.

We’ve been using triplit to store user settings that can be managed by admins, it’s important users always feel like the app runs locally and they often don’t have good internet but we still needed sync as the users often switch devices and admins need to see and manage other users settings.

Overall triplit has been really great, both as a frontend dx and also their support - whenever we find an issue or have a feature it gets handled very quickly by the team which is awesome!

As soon as they have an answer for HA deployments we will be moving more critical data there instead of Postgres

Why did you choose to license this under the AGPL?

I believe I saw your video presentations on YouTube [0] from the Local First Discord server [1], so nice to see your Show HN here. I am not using TypeScript so I might not be your target audience, I'm using local-first especially for mobile apps where connections can be spotty unlike the web which by definition (at least on first load) is always connected to the internet, and I'm using Flutter for this use case, as well as a backend in Rust. Other local first solutions are generally agnostic to the client and server because they work directly on the database layer, ie ElectricSQL and PowerSync will sync the client and server database. Other solutions with CRDTs can also work on the client and server with some FFI, ie automerge is in Rust so in my case it'll work via FFI on the Flutter side via flutter_rust_bridge (or WASM on the web) and of course on my Rust backend server, but it looks like you are looking to offer a more classic client-server syncing solution instead needing conflict free resolutions on disparate clients, ie the server is the source of truth.

So with all that, my question is, is there a reason you guys went with more of a full language level solution rather than being more agnostic to the client and server? It seems harder to support other languages and frameworks other than JS based ones in the future, but I suppose the market for that is already big enough. ElectricSQL etc also have SDKs for TypeScript as well as Flutter and others so they are similar to your solution but it seems like they can support more clients and servers in the future just by building SDKs for them.

Another question, looks like you eventually want to compete with Supabase but they are already experimenting with database level syncing and CRDTs in Postgres [2] and might catch up with your solution, any thoughts on that?

[0] https://www.youtube.com/playlist?list=PLTbD2QA-VMnXFsLbuPGz1...

[1] https://localfirstweb.dev/

[2] https://news.ycombinator.com/item?id=33931971

Since this is LWW, does it mean the amount of information on the client scale linearly with the number of operations? (meaning: the more users modify a database, the more the operations log grows)? Or do you do checkpoints? How does it scale space-wise when the user does millions of ops per day?

would be great to have Rust bindings so it could work with Tauri. With tauri growth and the upcoming mobile devices support coupled with SQLite recent hype, this could bridge the gap and solve many problems for offline-first apps, thus become the go to solutions for many dev shops.

I've been using Triplit on my React native app for a while and it works great. Highly recommend. It's the only local-first db that hits these points for me:

- Good sane query language (not SQL) - Great typescript support - Offline support - React native support

The cherries on top is that it's open source and self-hostable.

So it’s not possible to use this with an existing postgresql database?

This is really cool. Feels like the future of app development.

But also I’m getting old, and I had the same feeling when RethinkDB came out. Do you guys have any thoughts on how your system compares to what they were doing and what eventually happened to them?

I used to use the meteo framework before, and I think if it's similar. By the way, is it possible to use MongoDB on the server side and Triplit on the React side? Or do I have to use a new database called Triplit?"

This looks great! I would like to use this tool.

I'm looking through the docs for more info on this line:

> The server supports different storage adapters, such as SQLite

What are the other storage adapters? I may just be blind, so if so please forgive me!

Would this be pluggable to any backend? Like say, Ruby on Rails or ASP.NET?

Looks very useful. I didn't dive deep, but don't understand yet where you define access controls? I mean, How you say that a given Users can only Access their own data.

Wow, nice work. I will definitely try it out for my apps and backend. Do you have any benchmarks? Not sure about the AGPL licence

Pretty cool guys. It would be nice to know the differences to other local first like solutions out there.

What is Triplet’s syncing latency?

Remotely reminds of Joyent Slingshot. Oh, how times have changed.

Is there a pre-existing demo page.

Nice!

That's really interesting & cool - I'm gonna look into this for sure!

I'd like to mention the Meteor.js framework (https://www.meteor.com/) too, which is in a bit of a transitioning phase right now to Meteor version 3, but is a really amazing full-stack app building solution I and many others have been working with for ~10 years.

It has a lot of batteries included, build system, pluggable frontend frameworks, lots of libraries, based on node.js, meaning it's pretty much compatible with the Node.js environment.

It's based on a really pretty simple syncing strategy for years:

It's original client side data provisioning layer is based on having

a) MongoDB on the Server and b) a javascript-native implementation of a subset of MongoDB in the Client.

Using a publish / subscribe mechanism the client can subscribe to the subset of data relevant to his current view, eg. dependent on the current user & view.

Updating is theoretically possible by using a syncing mechanism via writes into the client database and an elaborate allow/deny mechanism, but in practice most people use the following simple workflow:

Meteor also provides a method-call-mechanism by which a client can call the server to do (or fetch) stuff. So that's basically RPC in a very simple but powerful format.

These methods also allow for "client side simulations", optimistic updates to the client side database, with the changes getting rolled back / updated once the server part of the method has done it's updating of the database.

So the workflow for working & updating data in the DB looks like this:

- Data is "canonical" on the server DB

- Client subscribes for the necessary data for its client side cache

- When the user triggers an action, the client calls a method on the server, eg: "likePost(post_id)"

    - The client side simulation can actually increase the like count on the "Post" document in the local minimongo database

    - The server then executes the method & increments the like count in its database, if the request is valid

- The client syncs its database after the method has completed to make sure its optimistic update lead to the same results as the server call did on the server.

- The client updates its UI always reactively as soon as the data in its local db has changed.

All of this is very performant as long as you keep it cool and subscribe only what's actually needed for the current view,

Oh, and all of this has fine grained reactivity, on the client. The whole solution is really powerful, while deceptively simple.

Having the same API on both client and server allows for "isometric" code, meaning code which runs on both the client and the server, so you don't have to have two different versions of helper code, which is really cool too.

Meteor.js is pretty much a bit like "the old PHP experience" to me: As a full Stack developer I can write powerful apps with only one codebase which is shared in parts between client and server.

Link to Pub/Sub docs: https://docs.meteor.com/api/pubsub Link to the Method docs: https://docs.meteor.com/api/methods

Looks like it could be a more batteries-included/opinionated alternative to RxDB (https://rxdb.info). The relational queries might help some people who tend to think in SQL as opposed to documents (as in CouchDB or MongoDB) and the WebSockets for synchronization will help people get started more quickly. (RxDB provides interfaces for those who want to implement their own storage engine and/or synchronization backend.)

This is just using sqlite under the hood and none of this will scale. Why build your own query builder as well when you could just hook in one of the many ORMs in the NPM ecosystem and add support for 50+ other databases. This also isn't really something you could drop into an existing project very easily. Overall, I'm not impressed.

Here are some other options I prefer:

https://feathersjs.com/ https://rethinkdb.com/

I used to work for a startup called TripIt 15 years ago. Took a double take when I saw your name.