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 is accepted locally, it is final and won’t be rejected by the server. This simplifies the programming model and means you don’t have to code for rollbacks.
PowerSync is a server authoritative system. Local writes are tentative and can be rejected at the server. You run an API on the write path and write logic to handle conflicts and rollbacks.
The different approaches come with different trade offs, both operationally and in terms of the programming model.
On the topic, if interesting, we have a list of alternative projects here: https://electric-sql.com/docs/reference/alternatives
Congrats, I'm so looking forward an idea or project where I can use electricsql
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)
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).
[1] https://electric-sql.com/