| Thanks for reading through and for these questions. I'll take them in their order: --- Auth / RLS Yes — LinkedQL works with Postgres Row-Level Security. Each LinkedQL connection is equivalent to a regular DB connection (e.g., new LinkedQLClient(connectionInfo) is like new pg.Client(connectionInfo)). There’s no new permission model to maintain — the DB remains the enforcement point. Live queries always execute under the same authenticated role you provided, so RLS policies apply on every refresh or incremental update. LinkedQL never uses a “superuser” backend that could widen visibility. -- Replication limits & scaling Right now, each database connection supports one logical replication slot. LinkedQL dedupes overlapping live queries on top of it — so 1,000 clients watching the same underlying SELECT only cost the DB one change stream. We plan to support a distributed architecture as well — multiple instances of the live query engine coordinating load for high-traffic deployments. --- Why an npm package (and future extension) Right now LinkedQL plugs directly into JavaScript apps, matching how many teams already query Postgres from frontend or backend code. We definitely have a Postgres extension in the roadmap for your exact use case – tighter operational integration. --- Schema migration story This is also one I’m personally excited about. We previously had an automatic schema versioning layer in the earlier LinkedQL prototype: https://github.com/linked-db/linked-ql/wiki/Automatic-Schema... https://github.com/linked-db/linked-ql/wiki/Migrations The goal in the current version is a cleaner rewrite of that whole feature. So, migration support is returning – with everything we learned in the previous baked in. For example, while the previous implementation of the diff-based migration feature spoke JSON for schema declarations, we plan to let that be pure SQL – yet, diff-based. --- Thanks again for the thoughtful look!
We can zoom into any other area of your choice. |