Live data from Hacker News

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

electric-sql.com

131–140 of 173 posts

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

#131
Do you have any plans on releasing an Ecto Client? Basically What I would like to do is deploy my phoenix app at the edge, and have a postgresql database centralized in some other region. Let's say for example my centralized postgresql is in us-west-2 and the client running in ap-southeast-1.

Would something like this be possible?

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

#132
post #102

Earlier quoted context omitted.

You are really taking the expression `shameless plug` to another level in this thread, aren't you?

Genuinely excited about this space and it's what I'm focused on full-time so definitely have thoughts to share. I am wary of self-promotion. I do want to contribute things that I feel are relevant to the discussion, since I assume folks would be interested to see different patterns/approaches around local-first/offline-first architecture.

> Genuinely excited about this space

You can only be genuinely excited if you don't need to add a link to your product when talking about it. This one was actually your most interesting reply, I shouldn't have posted about the high amount of mention to your own competitor project here.

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

#133
Congrats.

How does this deal with schema changes? We have a solution where old clients can store objects that have new fields unknown to the client. Then when the clients updates the data is visible.

Do you have client libraries for mobile? Swift & Kotlin?

Does it support partial sync and fetch when you need an “archived” item? In my experience you only want the “working set” of data on the client. Not everything.

Cool work! CRDTs are the solution to this.

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

#134
post #50
post #9

Is there any validation or authorization for changes being merged back into the root database? In a traditional client / server model, the server has an opportunity to validate each request and optionally reject it. The lower level you go with the sync protocol (data changes vs high level requests) the more difficult that becomes. Have you addressed that and, if so, how? What prevents a malicious client from send arb…

The route that we went with for PowerSync (disclosure: co-founder) is to allow to define your own function for handling writes, where you would use your (presumably existing) backend application API to persist the writes to Postgres. Therefore you can handle any validation/authZ/business logic for writes in your backend layer. The PowerSync client SDK still handles the queueing and retrying of writes so that they can…

Can you please stop posting as much about PowerSync on a Show HN thread centered on ElectricSQL?

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

#139
post #85
post #77

Is the SQLite embedded in the browser?

It is in Firefox. The SQLite team has been working on making WASM support first class, so should work anywhere WASM does.

Ok, so are you saying that currently Electric SQL only works with Firefox, but NOT with Google Chrome?

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

#140
I just looked at the size of Sqlite in the browser as sql.js compared to WASM Sqlite in the broswer. sql.js seems to be over 2MB and WASM sqlite in just 900k, is that right? If so then does this make WASM Sqlite quite a good contender to replace things like Alasql in the browser (which is around 400k). Anyway views on this ?
Post reply on HN