- 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.

---

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.

Happy to dig into internals if anyone’s curious — how live updates propagate, how JOINs and complex queries resolve, consistency expectations, worst-case scaling, etc.

To keep the main post short, here are deep-dive links if you want to explore:

• Live update mechanics https://linked-ql.netlify.app/capabilities/live-queries

• Engineering paper (replication pipelines, differential projection, query inheritance) https://linked-ql.netlify.app/engineering/realtime-engine

Totally open to questions — I’m hanging around the thread to learn what concerns matter most.