Skip to content

ADR 015: Timescale (or other timeseries database)

ADR 015: Timescale (or other timeseries database)

Date: 2025-11-07 Status: Proposed

Decision Makers: Achitects

Context

For CIVITAS/CORE V2 we need a cloud-native, open-source, and production-grade solution to store time-series data in our Kubernetes environments. It must support the same operational features as our PostgreSQL setup: backups and PITR, role and secret management, read replicas, multiple databases or clusters, and high availability.

Since CIVITAS/CORE V1 already depends on TimescaleDB and Stellio also relies on it, replacing it would be challenging.

Therefore, this ADR focuses on whether we should continue using TimescaleDB or if there are major reasons to switch.

A key consideration is licensing: Timescale DB comes in two editions, open source and community. Each editions comes with a different features set. Basically open source are some core features, but advanced features are part of the community edition. All open source features fall under Apache 2.0 license - which is OK for use. If we use community features, we must comply with the Timescale License ("TSL").

Checked Architecture Principles

  • [full] Model-centric data flow
  • [full] Distributed architecture with unified user experience
  • [full] Modular design
  • [full] Integration capability through defined interfaces
  • [full] Open source as the default
  • [full] Cloud-native architecture
  • [full] Prefer standard solutions over custom development
  • [full] Self-contained deployment
  • [full] Technological consistency to ensure maintainability
  • [full] Multi-tenancy
  • [full] Security by design

Decision

We continue to use TimescaleDB.

Licencing concerns: We are using or will use community features, thus we must comply with Timescale License ("TSL").

Under TSL, we are allowed to embed TimescaleDB in a Value Added Product, provided customers are not permitted (contractually or technically) to define/modify the Timescale schema (no DDL access), and we are not allowed to offer a “TimescaleDB as a service.

Concretely: the grant in §2.1(b) allows embedding if you notify customers of the TSL and prohibit schema changes; §2.2 bans DBaaS/SaaS where Timescale is offered to third parties for time-series DB functions.

If CIVITAS V2 translates user “models” into DDL internally (no customer DDL or schema control), that aligns with the Value-Added condition in §3.10(iii).

Consequences

  • We MUST notify useres that TimescaleDB is used
  • We MUST prevent users from using DDL (CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME SQL statements) technically, by translating user “models” into DDL internally
  • We MUST NOT offer a “TimescaleDB as a service” clearly
  • We SHOULD NOT permitt useres to use DDL contractually

Alternatives

See also

Edited by Patrick Kopp