Use case
Building change-detection and pub/sub primitives on libsql (similar to Honker, pg_notify style queues, durable streams).
PRAGMA data_version is the critical dependency — it provides a version counter that increments on every commit, enabling:
- Cross-process change detection via polling (1ms intervals)
- Push-like async semantics without a broker
- Detecting when another connection modified the DB
Currently libsql doesn't support PRAGMA data_version (shown in compatibility matrix as ❌).
Questions
- Why was data_version omitted? Architectural constraint, low priority, or something else?
- Would you accept a PR to implement it?
- Does it conflict with libsql's replication/distributed model?
For local-mode libsql (single DB file), data_version should be straightforward — it's a pager-level counter in SQLite. For libsql-server, it's trickier (need server-side tracking), but worth discussing.
Context
- data_version exists in SQLite since 3.3.7
- Used by better-sqlite3, Honker, and other change-tracking systems
- WAL mode + data_version enables efficient cross-process notifications
Would love to know the reasoning. If there's a fundamental reason it can't/shouldn't be implemented, I can explore alternatives.
Use case
Building change-detection and pub/sub primitives on libsql (similar to Honker, pg_notify style queues, durable streams).
PRAGMA data_version is the critical dependency — it provides a version counter that increments on every commit, enabling:
Currently libsql doesn't support PRAGMA data_version (shown in compatibility matrix as ❌).
Questions
For local-mode libsql (single DB file), data_version should be straightforward — it's a pager-level counter in SQLite. For libsql-server, it's trickier (need server-side tracking), but worth discussing.
Context
Would love to know the reasoning. If there's a fundamental reason it can't/shouldn't be implemented, I can explore alternatives.