matlin

Can you point me to what gave you this impression? We implement our own query engine for Triplit and use a fork of tuple-database[1] for storage which is low level database that can store to SQLite (we do on the server) but in the browser it uses either an in-memory btree or IndexedDB.

Regarding compatibility with our databases, we do have some internal experiments of running a Triplit Server in front of existing databases as almost like a syncing cache. Still very experimental but maybe you'd be more into that use case.

1. https://github.com/aspen-cloud/tuple-database

I don't have official measurements but it's fast enough for most things short of realtime cursors or anything updating on an sub-second interval--we'll be adding a presence API for things like that. It'll also depend on the complexity of the query.

Do you have a specific use case in mind?

Yep! We've just prioritized based on what's been requested in our Discord and surprisingly Svelte has been requested a lot more than Vue so we did that first but Vue is on the way.

I'm not a legal expert but my understanding is that your perspective is a common misconception.

I'd recommend reading this: https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html

Our hope with the AGPL license is that it will make Triplit easily self-hostable while ensuring that anyone who makes modifications contributes those back to the community.

Technically speaking both values are preserved in the history but only one "wins" because each attribute is a last-writer-wins register. This works for most use cases e.g. you wouldn't want two concurrent edits to checkbox to leave it simultaneous true AND false state.

However, when it comes to collaborative text you're absolutely right and support is on our roadmap. A researcher in this space has already implemented his collaborative sequence library on top of Triplit with the Quill text editor and you can check it out here: https://github.com/mweidner037/list-positions-demos/tree/mas...

Triplit does persist the history of edits to a given attribute but indexes on the latest values makes querying stay fast. However, LWW Registers by nature doesn't actually require storing the history that's just our current implementation that allows clients to sync efficiently even after being offline for a while.

In terms of scaling to a million-ops per day we are probably not quite there yet but one advantage to having the server be the authority is that, in the future, the Triplit server could track the timestamps that each client last synced at and progressively prune the history similar to how Postgres handles VACUUM'ing dead tuples.

There are a lot of new local-first tools these days but broadly speaking Triplit lends itself to more typical client-server applications with a central, authoritative server where other tools in this space are oriented around decentralization and server-agnostic systems.

I can't speak to RethinkDB's history but we're really focused on a specific use case which I think helps. Specifically, Triplit is made for web developers so we have great TS support, React and Svelte bindings, etc which makes adoption and marketing much easier.

We've setup a demo environment to get a feel for it here: https://demo.triplit.dev/

It's actually running two clients and the server inside the browser window so even though it's simulating real-world, it's the actual code that powers Triplit.

Specs: https://www.sightful.com/spacetop-g1

It's funny how similar the problems that affect a workstation in Antartica are to designing a robust mobile app.

I personally think all apps benefit from being less reliant on a stable internet connection and that's why there's a growing local-first movement and why I'm working on Triplit[1].

[1] www.triplit.dev

On first read I was thinking Evan's approach sounds pretty similar to Y.js but there's a callout at the differences:

"... what I implemented is similar to what Yjs does. Some high-level differences are that a) Yjs doesn't store delete sets explicitly and sends all of them all over again each time syncing starts and b) Yjs gives each insert an additional rightward pointer for resolving ordering between children with the same parent."

My hunch is that the winning strategy in this space is going to be a CRDT version of a Piece Table (the data structure that VS Code uses). Big advantage is that you can separate content (text buffer) from the ordering.

I also hope there's more energy spend thinking about how to adapt these data structures to popular databases which is the biggest hurdle in adopting them. I'm personally invested; trying to create the best first party solution for Triplit.

A researcher at CMU has been thinking about this and got his sequence CRDT working with Triplit among other database systems. https://mattweidner.com/2024/04/29/list-positions.html

It's unclear if this has any of Firebase's signature real-time capabilities.

Certainly, Supabase is living proof that there's major demand for the ergonomics of Firebase with the established SQL ecosystem; however, there still seems to be a gap of a real-time, syncing, relational data store.

That's what we are still hard at work creating at Triplit[1] while others are making strides to add this functionality to Postgres directly[2].

[1] https://github.com/aspen-cloud/triplit [2] https://electric-sql.com/

For folks using Typescript, we're building this for web development at Triplit. We support incrementally updating subscribed queries in real-time from server to client over web-sockets.

https://www.triplit.dev/

There's a whole host of similar solution in the local-first realm of software[1].

I'm biased but you should definitely try Triplit[2] if you want a super easy way to make real-time collaborative software that works seamlessly even when offline or on unreliable networks (like on mobile).

[1] https://localfirstweb.dev/ [2] https://triplit.dev

Yeah that is the crux of most modern three-tiered architectures (client<->server<->database) these days. We're working on simplifying this with a new concept: a full-stack database.

If you run an identical query engine on client and server and then sync data between them, a client can just write a normal query on the client and you get an optimistic response instantly from a local cache and then later a response from the authoritative server. Frankly, this is where most highly interactive apps (like Whatsapp, Linear, Figma, etc) end up anyway with bespoke solutions we're just making it general purpose.

Mobile networks in general also produce a lot of latency and often warrants a local first caching system on the client. If you want a LiveView like user experience but resilience to flaky network conditions, we just added Svelte 5 bindings to Triplit[1] which let's you write queries client-side and have them sync with a server over web-sockets. Probably not attractive to Elixir devs but if Svelte is your central focus, Triplit is a good option.

[1] https://www.triplit.dev/docs/frameworks/svelte

That's a great pointer seems like a many birds single stone solution!

Glad you think so! We don't have any written docs but I would be happy to help you migrate! You can email me or join our discord https://triplit.dev/discord

Triplit is pretty opinionated about how things get stored so it doesn't work with existing SQLite schemas. We support basic `like` operators for searching but are definitely interested in supporting full text search. If you want to try that out, we use Sqlite in our server implementation so you can see an example there: https://github.com/aspen-cloud/triplit/blob/main/packages/se...

That's awesome you've already considered of a similar design to Triplit. Re: storage, Triplit can basically bind to any storage capable of providing ordered key values so we have bindings for SQLite but in the browser you're best of doing either in-memory or IndexedDB (both of which are built-in), examples here: https://www.triplit.dev/docs/client-database/storage.

Regarding similar projects there are a few you can find on https://localfirstweb.dev/ but Triplit stands out in a few ways: * Support for an authoritative server * Provides an optional hosted cloud service * Relational querying without SQL * Partial replication (this is a big one) * Typescript schemas and type hinting in queries in return types

For more advanced CRDT stuff, the creator of the Fugue List CRDT, created [a Triplit-powered collaborative text editor](https://github.com/mweidner037/list-demos/blob/master/tripli...) using Quill and his [List Positions](https://github.com/mweidner037/list-positions) library that we plan to have tighter integrations with.

Yes that's pretty much what we're going for. I'm less familiar with DynamoDB Streams but we're taking inspiration from Postgres triggers https://www.postgresql.org/docs/current/sql-createtrigger.ht...

RxDB is just provides clientside querying and a sync protocol. Triplit is full stack in that it's designed to run on both client and server and will "just work" out of the box for end to end syncing, querying, and persisting data. Triplit supports relational querying.

Yep exactly. We also include a [Set CRDT](https://www.triplit.dev/docs/schemas#set) you can add to any entity.

In the future, we'll have an easier way to accomplish what Matt did out of the box so you can create re-orderable lists and collaborative text that are fast and seamlessly handle conflicts automatically

We're working on exactly this. You can already do this with Triplit but it's challenging to make an out of the box solution because each framework passes context/data different from server to client differently. There's a cool project called [Vike](https://github.com/vikejs/vike) that generalizes this pattern across SSR'd UI frameworks

The stars are disabled in light mode if you want to try that!

jitl's comment summarizes it well and I'd add that if you're building a highly interactive app (especially on mobile), you can't wait for network after each action before showing feedback to the user. If you do your app will feel janky and broken. So the solution is to show what you "optimistically" expect to happen in the UI before your request has even reached the server so each interaction feels instant. E.g. if you like Tweet in the app, it'll show a heart even if you're not connected to the internet and then in the background once it has a connection it'll sync up all of the pending request. This, however, can become tricky to implement and really hard to maintain as you add more features.

So Triplit does this all for you automatically with the mental model that your database queries automatically update when any data changes happen even if you're offline. Triplit takes care of reconciling this whether the request succeeds on the server and with concurrent changes from other users.

Exactly this ^

[I work on Triplit] Currently, You can accomplish this by pulling from Triplit with either a JS client that just subscribes to each collection or with the REST API but we're currently working on a way to define custom "triggers" on your Triplit Server so you could directly push into any other database as you'd like