Apps with large dataset have their own characteristics: they are more tolerant to slower initial sync. We can resume replication at point-in-time, so even if a shape takes long to load, we can resume replication at the point we started synching the shape.
We will be working on the engineering to handle transferring large shapes.
It works similarly: migrations flow as part of the replication stream and clients apply them immediately, so that new data fits the local schema. New columns and etc might not immediately be exposed to the client app, but everything will works for old clients.
You definitely can do row-level filtering (and a lot more) using DDLX[1], an extension we made to Postgres language that allows expressing flexible permission rules in a data-centric way.
Handling encryption/decryption of user data is one of our priorities. We're thinking along the lines of adding hooks for transforming data as you're seeing it.
We're getting there on permissions implementations. If you want to do row-based filtering based on user_id today, you can add a special column 'electric_user_id' to your table: https://electric-sql.com/docs/reference/roadmap#shapes
We plan to integrate Electric with popular web frameworks: https://electric-sql.com/docs/integrations/frontend. To integrate with Angular, the client should work out of the box. What you'd need is to provide is the code for reactivity, which should not be a lot. Reach out on Discord and we can have a chat about it.