sqlsync VS triplit

If you're looking for a very real use case of SQLite in the browser, there's SQLSync[1]. It was recently discussed on HN[2].

[1]: https://sqlsync.dev/posts/stop-building-databases/, https://sqlsync.dev/

No, there is a client part: https://github.com/orbitinghail/sqlsync/blob/main/GUIDE.md

> Step 2: Install and configure the React library

Here's another local-first collaborative component: SQLSync [0]

[0] https://github.com/orbitinghail/sqlsync

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...

Your app might not need it but if you want partial replication or relational querying in addition to offline-first syncing then check out https://github.com/aspen-cloud/triplit (disclaimer: I'm working on this)

I'm currently writing a very similar article about "full-stack databases" which highlights the same pattern where many apps end recreating the logic of our backend and database in the frontend client code. The solution we're promoting is to choose a database that can run on both the server and in the client and then sync between them.

The reason we aren't using Sqlite for our product is because Sql is frankly not the right tool for querying data for an application. It doesn't easily map to the data-structures you want in your client code and nearly all SQL databases have no way to subscribe to changes to a query without polling the query repeatedly.

So if you like the idea of having a complete database on your client but also want deep integration with Typescript/Javascript check out what we're building at https://github.com/aspen-cloud/triplit