Live data from Hacker News

Show HN: Bi-directional sync between Postgres and SQLite

powersync.com

101–107 of 107 posts

Re: Show HN: Bi-directional sync between Postgres and SQLite

#101
I'm excited for the Capacitor SDK that's on the roadmap. Any rough ballpark estimate of when that might be available?

I haven't used Capacitor but I will soon. Is it possible to use the web SDK in a mobile Capacitor app or is there something about the webview browser environment that breaks the normal functioning of Powersync on the web?

Re: Show HN: Bi-directional sync between Postgres and SQLite

#103
post #56
post #54

This looks interesting! How does this compare to ElectricSQL[1]? Next to not using CRDTs. [1] https://electric-sql.com/

Hey, James here from Electric. Congratulations to the PowerSync team :) As a sibling comment says, PowerSync actually wrote up a comparison here https://www.powersync.com/blog/electricsql-vs-powersync Aside from Electric being open source and PowerSync a proprietary service, the primary difference is in the programming model on the write path. Electric provides finality of local writes. So once a non-malicious write…

Wow the amount of effort you have put in this open source project is incredible!

Congrats, I'm so looking forward an idea or project where I can use electricsql

Re: Show HN: Bi-directional sync between Postgres and SQLite

#104

I'm excited for the Capacitor SDK that's on the roadmap. Any rough ballpark estimate of when that might be available? I haven't used Capacitor but I will soon. Is it possible to use the web SDK in a mobile Capacitor app or is there something about the webview browser environment that breaks the normal functioning of Powersync on the web?

It may be possible to use the web SDK directly in a Capacitor app - it could be sufficient for initial development, but I wouldn't recommend that for production use. It would use the webview's IndexedDB as for persistence, which is not ideal for a native app. For the Capactitor SDK, we would use native SQLite, which would have better performance and more control over storage.

Re: Show HN: Bi-directional sync between Postgres and SQLite

#105
post #56
post #54

This looks interesting! How does this compare to ElectricSQL[1]? Next to not using CRDTs. [1] https://electric-sql.com/

Hey, James here from Electric. Congratulations to the PowerSync team :) As a sibling comment says, PowerSync actually wrote up a comparison here https://www.powersync.com/blog/electricsql-vs-powersync Aside from Electric being open source and PowerSync a proprietary service, the primary difference is in the programming model on the write path. Electric provides finality of local writes. So once a non-malicious write…

I looked at these two systems recently and noted another crucial difference for anyone using them for a use case that included access control. ElectricSQL doesn't seem to (yet) support table joins in a way that would support standard web app access control design patterns. If you're replicating a table to a device, you're replicating the entire table, not a user-limited selection.

Supporting joins is in development, but I'm not yet clear on whether the current dev branch on it goes far enough to support access control use cases.

There's a hack in place that's supposed to help - you can define an electric_user_id on the table - but that isn't actually usable in the majority of use cases, because most ACL cases include records where multiple users can access it. I did explore using views, but electricsql doesn't currently support postgres views.

(if I'm wrong or missed something in electricsql, I'd love to be corrected, as it looks like an exciting project otherwise)

Re: Show HN: Bi-directional sync between Postgres and SQLite

#106
post #56

Earlier quoted context omitted.

Hey, James here from Electric. Congratulations to the PowerSync team :) As a sibling comment says, PowerSync actually wrote up a comparison here https://www.powersync.com/blog/electricsql-vs-powersync Aside from Electric being open source and PowerSync a proprietary service, the primary difference is in the programming model on the write path. Electric provides finality of local writes. So once a non-malicious write…

I looked at these two systems recently and noted another crucial difference for anyone using them for a use case that included access control. ElectricSQL doesn't seem to (yet) support table joins in a way that would support standard web app access control design patterns. If you're replicating a table to a device, you're replicating the entire table, not a user-limited selection. Supporting joins is in development,…

This page lists current limitations https://electric-sql.com/docs/reference/roadmap

The key features for us on this are:

1. permissions https://electric-sql.com/docs/usage/data-modelling/permissio... which are defined using DDLX rules, authorise data access and can be used to filter data 2. shapes https://electric-sql.com/docs/usage/data-access/shapes which are the main, more expressive way to control what data syncs on and off the local device, including where clauses, joins, include trees, etc.

These are both in development and due soon. From your comment, I think you’ve seen the shapes branch with where clauses and include trees already working, for example.

In the meantime, the shapes API over syncs the full table. This is temporary and obviously suboptimal but it means you can develop today using the shape APIs and still filter data you display using local queries. Then when the proper functionality lands, the sync will become more fine grained and optimal without your app code needing to change.

Hope that makes sense. We’re very much not a full table sync system. Our role is to provide the best possible model for controlling dynamic partial replication (and to maintain integrity across replication boundaries).

Re: Show HN: Bi-directional sync between Postgres and SQLite

#107

Earlier quoted context omitted.

I looked at these two systems recently and noted another crucial difference for anyone using them for a use case that included access control. ElectricSQL doesn't seem to (yet) support table joins in a way that would support standard web app access control design patterns. If you're replicating a table to a device, you're replicating the entire table, not a user-limited selection. Supporting joins is in development,…

This page lists current limitations https://electric-sql.com/docs/reference/roadmap The key features for us on this are: 1. permissions https://electric-sql.com/docs/usage/data-modelling/permissio... which are defined using DDLX rules, authorise data access and can be used to filter data 2. shapes https://electric-sql.com/docs/usage/data-access/shapes which are the main, more expressive way to control what data syncs…

I cannot imagine advocating for using shapes as they currently exist for an access control use case. Shapes may limit what the user can see in the app, but I've now put all of my other users data on this user's device! No way can I pass a security audit with that.
Post reply on HN