LinkedQL is written in JavaScript and runs in both client and server environments.
GitHub + docs: https://github.com/linked-db/linked-ql
Demo examples included.
I’d love feedback: • Anything confusing? • Anything seems useful or dangerous? • Anything else that'd make you consider LinkedQL for production?
Thanks for taking a look — happy to answer any questions.
- 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.
phrasecode•5h ago
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.