3 ms·

A few questions/comments after skimming the docs: - How does authz work? Can I use Postgres RLS? If not, how would you address row or column-level permissions

by ilkhan4 10mo ago

A few questions/comments after skimming the docs: - How does authz work? Can I use Postgres RLS? If not, how would you address row or column-level permissions in a system that uses this? - If you're using logical replication to sync with PG, is there a limit to the number of clients you can have connected? I see there is a lot of work around de-duping live queries, but how well does that work in practice? - Any thought to making an extension for Postgres? My main hesitation right now is that I have to go through an NPM package to use this but a lot of our tooling expects a plain Postgres connection. - REALLY looking forward to seeing how the schema migration story looks. Overall, it seems to address most of the use-cases where I'd reach for an ORM or API server so I'm really interested to see where this could go.

phrasecode 10mo ago
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-Versioning https://github.com/linked-db/linked-ql/wiki/Automatic-Schema... https://github.com/linked-db/linked-ql/wiki/Migrations 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.

by ilkhan4 10mo ago

phrasecode 10mo ago

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-Versioning https://github.com/linked-db/linked-ql/wiki/Automatic-Schema... https://github.com/linked-db/linked-ql/wiki/Migrations 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.