Live data from Hacker News

Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

electric-sql.com

31–40 of 173 posts

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#32
I want to be able to have a Postgres database as the central source of truth for all data and user accounts, but then have each users private content to be siloed and synced to their own SQLite database which they alone have access to (maybe even they’re have one SQLite file on server and one SQLite file on phone or etc.). Is this possible with electricSQL? I remember looking at it a year ago or so and was excited but not sure if worked for my use case. Great work tho looks really good and very much in line with what I’d like to be able to do.

Also is there a way to transition an existing Postgres data base into using electicsql?

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#33

Congrats on the launch and interesting project! I have a lot of questions :) * I am by no means a crdt expert, but from my tinkering I have come to the opinion that the upside of the consistency does come at the cost of ease of understanding how state ends up how it does, which can bleed into user facing issues if how a crdt converges conflicts with intuition. A lot of that seems like an education and design problem…

Hey, thanks :)

We have a Discord if you fancy chatting at more length! https://discord.electric-sql.com

Re: CRDTs and intuition, yup, there's trade offs. We are working hard to deliver a solid model to code against. So we have finality of local writes and standard relational integrity guarantees. You can read a bit more about some of techniques here https://electric-sql.com/blog/2022/05/03/introducing-rich-cr...

Re: electrify yes, we create a shadow table and some operation log tables etc. So there is some storage amplification but it's of the order of 2x (we use operational based CRDTs and we garbage collect the operation log). We see the fit being with standard OLTP workloads, mainstream relational apps. We don't target high volume data ingestion, etc.

Re: commercial model, we're designed for open source self-host. We see Electric as a drop in sync layer, not as a full stack backend-as-a-service. Lots of options but concentrating on product for now.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#34

I want to be able to have a Postgres database as the central source of truth for all data and user accounts, but then have each users private content to be siloed and synced to their own SQLite database which they alone have access to (maybe even they’re have one SQLite file on server and one SQLite file on phone or etc.). Is this possible with electricSQL? I remember looking at it a year ago or so and was excited bu…

Hey,

This is the exact pattern we target :)

Drop Electric onto an existing Postgres data model and use the Shape-based sync to manage dynamic partial replication of subsets of data between central Postgres and local SQLites: https://electric-sql.com/docs/usage/data-access/shapes

James

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#36

Can you delve a bit deeper into how WASM works? Specifically, how heavy is the WASM module? Also, is there a specific use-case you've seen where this shines particularly brightly?

Hey, I work for Electric.

The WASM module is just a standard build of SQLite, about 1.1mb - there are many landing pages 10x that size - and something that we think is easily justifiable for the types of apps that people can build with Electric.

In terms of use cases, there are numerous, broad-ranging possibilities - anything from a replacement for GraphQL or a REST API in your existing stack, all the way up to building large collaborative apps. Our intention is that you can build collaborative tools similar to Linear, and we do actually have a demo of this sort of thing (http://linear-lite.electric-sql.com), but it’s certainly not limited to that.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#37
post #30

Are there plans for a true native driver (not JS)? That's kind of a dealbreaker in the same groups that are looking for offline first.

There will be other drivers. We are exploring ways to support a wide range of os/platforms but this is a little way off, for now we are concentrating on the js client.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#39
post #20

Awesome! I'm looking forward to trying this out. Currently I get this functionality by using PouchDB on the client with a CouchDB sever. Then on my API server I have some janky code in a cron job to sync changes from CouchDB to PostgreSQL.

Hey, I work at Electric,

The CouchDB/PouchDB pattern is how I originally got interested in local first, they are such a good tool, but having the full power of Postgres and then SQLite on the client, I believe, is a real game change.

Sounds like Electric could be a really good fit for your use case. If want any advice join the Discord and we are happy to help out.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#40
Congrats to the team. I'm on the team over at https://powersync.co and have been following this space for a while.

PowerSync is also a plug-in sync layer. The biggest difference I see is in Electric's use of CRDTs, where we don't rely on them and instead use server reconciliation.

As a team that's been working on online/offline sync for just over a decade, it's great to finally see more products that enable offline-first architectures!

Post reply on HN