[GH#261] [Future] Evaluate whether long-term telemetry analytics should remain in SQLite or move to a secondary local analytics store #25

New issue

Open

opened 2026-05-19 22:15:44 +02:00 by Max · 0 comments

Max commented

2026-05-19 22:15:44 +02:00

Owner

Migrated from GitHub #261
Originally created by @Bio1988 on 2026-04-23T09:42:59Z

Context

Post-MVP follow-up from the telemetry/SQLite discussion.

Current conclusion: SQLite remains the best default local system of record for the product now, especially with WAL mode, queued writes, and batched persistence. The open future question is whether very large historical telemetry analytics should continue to live only in SQLite or whether a secondary local analytics store would later make sense.

Why this is future work

This is not an MVP blocker. The current recorder is local-first and should remain low-friction. Any additional analytics store would add complexity and should only be introduced if the product later needs it.

Question

If the product eventually needs heavier historical telemetry analysis, would a secondary local analytics store such as DuckDB or Parquet-backed exports be justified, while SQLite remains the operational system of record?

Scope

compare the current SQLite-only direction against a hybrid model:
- SQLite for operational local storage and replay
- optional secondary analytics/export format for large historical analysis
evaluate local-only deployment cost on Windows
evaluate query ergonomics, retention behavior, and export/import complexity
define the threshold at which the extra store becomes worthwhile

Acceptance criteria

documented recommendation: keep SQLite only, or add an optional secondary analytics path later
recommendation explicitly preserves SQLite as the operational/local system of record unless an ADR says otherwise
product and engineering tradeoffs are written down clearly

Notes

This is explicitly future-facing. The immediate storage work should stay focused on correctness, retention, session identity, and hot-path isolation.

Migrated from [GitHub #261](https://github.com/Bio1988/strategy-desktop/issues/261) Originally created by @Bio1988 on 2026-04-23T09:42:59Z --- ## Context Post-MVP follow-up from the telemetry/SQLite discussion. Current conclusion: SQLite remains the best default local system of record for the product now, especially with WAL mode, queued writes, and batched persistence. The open future question is whether very large historical telemetry analytics should continue to live only in SQLite or whether a secondary local analytics store would later make sense. ## Why this is future work This is not an MVP blocker. The current recorder is local-first and should remain low-friction. Any additional analytics store would add complexity and should only be introduced if the product later needs it. ## Question If the product eventually needs heavier historical telemetry analysis, would a secondary local analytics store such as DuckDB or Parquet-backed exports be justified, while SQLite remains the operational system of record? ## Scope - compare the current SQLite-only direction against a hybrid model: - SQLite for operational local storage and replay - optional secondary analytics/export format for large historical analysis - evaluate local-only deployment cost on Windows - evaluate query ergonomics, retention behavior, and export/import complexity - define the threshold at which the extra store becomes worthwhile ## Acceptance criteria - documented recommendation: keep SQLite only, or add an optional secondary analytics path later - recommendation explicitly preserves SQLite as the operational/local system of record unless an ADR says otherwise - product and engineering tradeoffs are written down clearly ## Notes This is explicitly future-facing. The immediate storage work should stay focused on correctness, retention, session identity, and hot-path isolation.

Max added the

labels

2026-05-19 22:15:44 +02:00