Show HN: LinkedQL – Live Queries over Postgres, MySQL, MariaDB

Thanks for spotting that — to clarify: the current production implementation of Live Queries is Postgres only.

MySQL/MariaDB support is in progress (binlog-based) and is why the docs say “coming soon.”

The post wasn’t meant to imply that MySQL/MariaDB are already live; the intention was to describe the overall design rather than claim full parity. I’ll update the wording to avoid that confusion.

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.

Ah yes — good catch. The commit history definitely isn’t following Conventional Commits right now. Things got a bit loose during fast iterations, but I’ll follow the convention going forward.

Author here — thanks for checking it out.

Short answer: the core LinkedQL live query engine runs on the backend today, and there’s an embeddable variant (FlashQL) that runs directly in the frontend with the same LinkedQL capabilities – live queries, DeepRefs, etc.

1. Pure frontend / local data

For data that can live entirely on the client, you can spin up an in-browser FlashQL instance:

const client = new FlashQL(); // runs in the page / worker

await client.query(` CREATE TABLE users ( id UUID PRIMARY KEY, name TEXT ) `);

// Live query works the same way as on the backend: const result = await client.query( 'SELECT * FROM users', { live: true } );

From there, result is a live result set: inserts/updates/deletes that match the query will show up in the rows, and all the same features (live queries, DeepRefs, etc.) behave as they do on a backend instance.

At the moment FlashQL is in-memory only; persistence backends like IndexedDB / LocalStorage are on the roadmap.

2. Remote database from the frontend

If your source of truth is a remote Postgres/MySQL instance, the model we’re building is:

a LinkedQL engine next to the database, and

a FlashQL instance in the frontend that federates/syncs with that backend engine.

That federation/sync path is in alpha right now (early docs here: https://linked-ql.netlify.app/flashql/foreign-io ), so today the “stable” story is:

run LinkedQL on the backend against Postgres/MySQL,

expose whatever API you like to the frontend,

and use FlashQL locally where a client-side store makes sense.

The goal is that the frontend doesn’t need a special framework — just a LinkedQL/FlashQL client wherever JavaScript runs.

Author here. Sad to hear that you perceive the docs and comments here as LLM generated. I'm genuinely curious what in particular gives you that impression.