Skip to main content
Version: 2.0-rc2

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 ADRArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. 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​