[phrasecode]

Would you clarify what a "transaction" in this instance would mean?

LinkedQL definitely optimizes at multiple levels between a change happening on your database and the live result your application sees. The most significant of these being its concept of query windows and query inheritance which ensure multiple overlapping queries converge on a single "actual" query window under the hood.

You want to see the engineering paper for the full details: https://linked-ql.netlify.app/engineering/realtime-engine

[sureglymop]

Database transactions. Sometimes, when you require exceptionally high throughout and performance, it can be a viable strategy to batch multiple operations into the same transactions in order to reduce roundtrips, io and network latency.

Of course, it comes at the cost of some stability. However I was just curious if such an abstraction could support such use cases. Thank you for the link to the paper!

[phrasecode]

You're welcome.

And of course achieving that "exceptionally high throughput and performance" is the ultimate goal for a system of this nature.

Now, yes — LinkedQL reasons explicitly in terms of transactions, end-to-end, as covered in the paper.

The key structural distinction is that LinkedQL does not have the concept of its own transactions, "since it doesn’t initiate writes". Instead, it acts as an event-processing pipeline that sits downstream of your database — with a strict "transaction-through rule" enforced across the pipeline.

What that transactional guarantee means in practice is this:

Incoming database transactions (via WAL/binlog) are treated as "atomic" units. All events produced by a single database transaction are received, processed, and propagated through the pipeline with their transactional grouping preserved, all the way to the output stream.

Another way to think about it:

You perform high-throughput writes (multi-statement transactions, bulk writes, stored procedures, batching, etc.)

  → LinkedQL receives the resulting batch of mutation events from that transaction
  → processes that batch as "one" atomic unit
  → emits it downstream as "one" atomic unit
  → observers bound to the view see a "single" state transition composed of many changes, rather than "a flurry" of intermediate transitions.

Effectively, a systems that thinks in terms of batching and other throughput-oriented write patterns. LinkedQL just doesn’t initiate its own transactions — it preserves yours, end-to-end.