Skip to main content

ADR 010: Select DBMS

Date: 2025-09-15

Status: Accepted

Decision Makers: @JulianSobott @cr0ssing @luckey @DerLinne

Context​

We need a DBMS to store data from different services. In Civitas v1, Postgres was used for this. One central DBMS is preferred over one DBMS per service because it makes managing the DBMS much easier. Tasks such as access control, backups, logging, monitoring, performance optimizations, and security only need to be set up once. New services can be easily added. The platform needs to store, among other things, geodata, time series data, and vectors.

Checked Architecture Principles​

  • [none] Model-centric data flow – Postgres schemas can be migrated via migration tools
  • [partial] Distributed architecture with unified user experience – Using a central DBMS reduces distribution and creates a single dependency, which contradicts the principle of distributed components. However a central DBMS can be seen as infrastructure which is expected to work.
  • [full] Modular design – Postgres is only used for storing data and no logic.
  • [full] Integration capability through defined interfaces – Postgres offers well-documented, standard SQL and supports APIs (JDBC, ODBC, PostGIS, FDW). It should be noted, that postgres extends the standard sql with new functions, which can make it hard to switch to another sql DBMS.
  • [full] Open source as the default – Fully open-source, strong community, long-term sustainability.
  • [full] Cloud-native architecture – Mature Kubernetes operators exist (e.g., CrunchyData, Zalando), supports containerization, scaling (within limits), backups, HA.
  • [full] Prefer standard solutions over custom development – Postgres is a widely adopted standard DBMS
  • [full] Self-contained deployment – Can be deployed and operated entirely inside Kubernetes with operators, optional to connect to external DBaaS.
  • [full] Technological consistency to ensure maintainability
  • [full] Multi-tenancy – postgres supports 4 patterns: shared tables (certain apps might use this), schema per tenant, database per tenant or cluster per tenant.
  • [full] Security by design – Strong security features (roles, fine-grained access control, SSL, auditing). Centralization may increase blast radius but simplifies consistent security enforcement.

Decision​

Postgres should be used as the central DBMS. It worked very well in v1, is well maintained, and satisfies all of our requirements.

Consequences​

We should choose tools, which support postgres/sql.

Alternatives​

  • MariaDB/MySQL: less advanced geospatial/time-series ecosystem than Postgres (PostGIS, Timescale).
  • MongoDB: Flexible schema-less design, good for unstructured/JSON-heavy data; weaker for relational queries and complex geospatial/time-series compared to Postgres. Only few tools use/support mongodb
  • Other NoSQL (e.g., Couchbase, ArangoDB): Offer document storage and some graph/time-series features; smaller ecosystems and less Kubernetes maturity than Postgres/MariaDB/MongoDB.

See also​