Databases & Data Stores
Want to propose a change, disagree with a placement, or add an interesting new technology? Please reach out to @Damian Szafranek. This Tech Radar is a living document - we keep it useful by updating it together as our projects, tools, and experiences evolve.
Scope
This section covers the technologies we use for data persistence, storage, and management. It includes our standard relational databases, tools for schema migration, and specialized data stores for caching or search.
Overview
ADOPT
Proven technologies we have high confidence in; our default choices.
HOLD
Not recommended for new work; plan migration from existing uses.
Technologies Breakdown
PostgreSQLADOPT
Our default relational database for most new systems. Reliable, well-supported, and a strong “general-purpose” choice.
PostgreSQL remains the primary go-to when we need a mature SQL database with great ecosystem support, strong consistency, and solid performance across a wide range of workloads. It’s separated from the MySQL line to make the default choice clearer and to reflect that Postgres is typically our first pick unless there’s a specific reason not to.
MySQL/MariaDBADOPT
A practical alternative relational database line. Use when MySQL compatibility is required, with MariaDB as a preferred option where applicable.
We keep MySQL-compatible databases on the radar for projects where that ecosystem is expected (existing deployments, hosting constraints, vendor requirements). MariaDB is often a comfortable choice in this family (including cases where teams prefer to avoid the Oracle association). Treat this as the “MySQL world” option—use intentionally, not by default.
Flyway & Liquibase ADOPT
Both are our supported tools for managing database schema migrations. They ensure that database changes are automated, version-controlled, and repeatable across environments. While both are adopted, teams should aim for consistency within a single project.
MongoDB TRIAL
Document-oriented NoSQL database for cases where flexible schemas and JSON-like data models are a better fit than relational design.
MongoDB can work well when your domain naturally maps to documents, when schema evolves rapidly, or when you want to avoid heavy relational modeling. It’s not a universal replacement for SQL. Use it when the document model is clearly advantageous and you’re ready to handle the trade-offs (data modeling discipline, query patterns, consistency expectations).
RabbitMQ TRIAL
Message broker for asynchronous processing and reliable integration between services when you need explicit messaging patterns.
RabbitMQ is useful for decoupling services, buffering spikes, and implementing queues/pub-sub workflows with strong delivery semantics. It’s powerful, but it adds operational and architectural complexity. Use it when messaging is a core requirement, not as a default for every integration.
Redis TRIAL
In-memory data store for caching and fast data structures. Use to boost performance and reduce load on primary systems.
Redis is a great fit for caching (API responses, computed results), short-lived state, rate limiting, and lightweight shared coordination. Introduce it when you have a real performance/latency need and clear cache semantics; avoid “cargo cult Redis” when a simpler approach is enough.
DynamoDB ASSESS
AWS-native NoSQL key-value / document store. Best for AWS-centric systems that need predictable scaling and low operational overhead.
DynamoDB can be an excellent fit for specific access patterns (key-based lookups, well-defined queries) and workloads that benefit from managed scaling. It requires careful up-front data modeling around access patterns, so it should be chosen intentionally. Especially when running fully in AWS and when its trade-offs match the domain.
Oracle DB & Microsoft SQL Server HOLD
The use of these proprietary databases is restricted to projects with explicit client requirements. We are putting them on hold for any new, internally-driven projects to limit licensing costs and focus our expertise on our open-source standards.