How far to be production ready?

[MirjamElad]

Hello and thank you for this interesting project. It's all in the title. I really like the paradigms of LinkedQL and FlashQL and I am tempted to use it in a coming project.
As stated in the README, the project is not ready for production yet. Can you give some estimate on when it will be ready for production apps.
If possible, please provide a timeline to let early adopters check when the features they care most about will be ready (and plan accordingly).
Thanks again and good luck with this promising project.

[ox-harris]

Oh yes — that’s exactly the next question, and a positive one for me.
Also, thanks for the encouraging tone. That kind of energy really helps.

One thing I should probably clarify first is: when the README says “not production-ready,” it’s less about a strict checklist and more about a social milestone driven by usage. That’s just the reality with new projects like this. They don’t mature in isolation — they mature by being used, stressed, misused, questioned, and pushed into corners you couldn’t have predicted upfront.

So the biggest difference between “current status” and “production-ready” isn’t really missing features. It’s simply not enough real-world usage yet to guarantee production status. But that changes quickly as discovery improves. (I’ve been circling around a proper launch post for LinkedQL to help kickstart that process. The sooner LinkedQL is widely seen and tried, the sooner it gets battle-tested — and the sooner the README can honestly say: yes, people are running this in production.)

That said, there are a few concrete areas where there’s an actual checklist. Here’s a quick snapshot of what’s actively in flight:

Test coverage
LinkedQL already has 500+ test cases, but more coverage always means stronger guarantees. This is ongoing and benefits directly from real usage and reported edge cases.

Core implementation

• FlashQL (the in-memory runtime)
  Persistent storage isn’t wired in yet, but that work is already happening via a separate reusable project, Keyval:
  https://github.com/webqit/keyval
  I’m hoping to integrate Keyval into LinkedQL within days, which unlocks persistence without bloating the core.
• Federation & sync
  These are currently alpha. They work, but they’re still being validated and should move toward beta as usage increases.

Database adapters

• PostgreSQL is currently the most complete backend.
• MySQL/MariaDB isn’t on parity yet — most notably, live queries are still incomplete there.

Overall, if you’re planning a project, it’s mostly game-on from my side. You should feel free to move forward and circle back as you go — I’m more than happy to walk the journey with you and learn in the process. Early adopters genuinely help accelerate the “production” timeline, because “production” here isn’t a single release switch.

[hyusetiawan]

i am very tempted to use this for my agency, we are doing some ad hoc eventing for our graphql with a really dumb logic (if there is a mutation to the table rows, just broadcast) and it ends up being really chatty. This would fit really really well. My suggestion to you is to add a first class integration to the popular ORMs like drizzle or prisma, I feel like this will be cheap to implement with huge marketing returns.

[ox-harris]

Hey — this is a really familiar problem.

What you’re running into usually happens when subscriptions are tied to tables or broad change streams instead of the actual query shape you care about.

That’s where things start getting noisy: lots of irrelevant events, and in an RLS-heavy setup, it can also increase connection fanout due to duplicated subscription scopes across policies and roles.

The way LinkedQL is meant to avoid that is by not treating this as “table change → broadcast”, but as query-scoped reactivity.

So instead of:

“this table changed, notify everyone”

it’s:

“this specific query result set is affected, notify only those subscriptions”

That’s the core shift.

Coincidentally, LinkedQL also does expose a lower-level, table-level changefeed built directly on WAL. But it's not exactly the model you run currently. This is actually a commit stream, where each event represents a commit containing one or more row-level changes. Meaning, less noise.

So, with LinkedQL two ways to react to changes:

• Live Queries (db.query({ live: true })) – sits on top of query evaluation
• WAL Changefeeds (db.wal.subscribe()) – sits below that (commit-level stream, not change-level)

but build for different use cases.

On integration: you don’t need to give up Drizzle/Prisma.

A simple pattern is:

const { sql, params } = drizzleQuery.toSQL();
await db.query(sql, { values: params, live: true });

So:

• ORM → schema + SQL generation
• LinkedQL → execution + realtime layer

Depending on what you're building...

If you later care about things like local-first or offline support, FlashQL (federation + sync) solves that neatly — but you don’t need that to get value here.

Here are docs that might map directly to what you’re describing:

• Live Queries: https://linked-ql.netlify.app/capabilities/live-queries
• Changefeeds: https://linked-ql.netlify.app/capabilities/changefeeds
• Integration Patterns: https://linked-ql.netlify.app/docs/integration-patterns
• Federation + Sync (optional next step): https://linked-ql.netlify.app/flashql/federation-and-sync