[HN Gopher] Show HN: LinkedQL - Live Queries over Postgres, MySQ...
___________________________________________________________________
Show HN: LinkedQL - Live Queries over Postgres, MySQL, MariaDB
LinkedQL is a new SQL client that supports live queries over any
Postgres, MySQL, and MariaDB database. You get result sets that
self-update differentially as rows change in your database - via
inserts, updates, deletes. Works with no extra tooling/ORM layer or
GraphQL servers. You opt into live mode simply with a flag:
client.query('SELECT ...', { live: true }). More at:
https://linked-ql.netlify.app/capabilities/live-queries 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.
Author : phrasecode
Score : 20 points
Date : 2025-12-08 14:23 UTC (5 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| phrasecode wrote:
| Author here -- a bit more detail on architecture and guarantees
|
| 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.
| ilkhan4 wrote:
| 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 wrote:
| 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.
| nthypes wrote:
| How you solve scale of Live queries different from Zero sync?
| zero.rocicorp.dev
| necubi wrote:
| The docs and the comments here are clearly LLM generated. Please
| don't submit AI slop to HN, or at the very least talk about it in
| your own words!
|
| The commit history is legitimately insane though:
| https://github.com/linked-db/linked-ql/commits/master/
| phrasecode wrote:
| 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.
| esafak wrote:
| Please follow https://www.conventionalcommits.org/
| phrasecode wrote:
| 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.
| nthypes wrote:
| This is an backend library? How to enable Live queries in the
| frontend?
| phrasecode wrote:
| 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.
| evanelias wrote:
| Your docs say live queries for MySQL and MariaDB are "coming
| soon", but your post here strongly suggests they're already
| supported. Is this actually implemented yet or not?
| phrasecode wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-13 23:01 UTC)