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
Where data lives and how we reach it: relational databases, document stores, caches, message brokers, the ORMs we query through, and the tools that migrate a schema. Managed cloud data services belong here too, even though they are also infrastructure, because the question a reader is asking is what to store data in.
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
PostgreSQL ADOPT
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/MariaDB ADOPT
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.
SQLModel ADOPT
Worth using as the ORM on a Python service that already uses Pydantic, since the same model definition serves both the database and the API schema.
On the LLM platform we delivered in 2026 its value came from what a shared base class made possible rather than from the ORM itself. One base gave every table a UUID primary key, soft deletion, and a helper that excludes deleted rows by default, so nobody has to remember the filter. Forgetting that filter had been the most common mistake found in review, and the base class removed the category rather than the instances.
Alembic ADOPT
The migration tool for SQLAlchemy and SQLModel projects, and the Python counterpart to Flyway and Liquibase. Enforce a single migration head in continuous integration.
Sixty-five migrations on the LLM platform we delivered in 2026 without incident. The configuration worth copying runs three modes from one file: async for applying migrations, offline for emitting SQL only, and synchronous for tests, where migrations execute and roll back inside the same transaction as the test. A continuous integration gate on there being exactly one head catches the branching problem early, since multiple heads otherwise only surface when someone runs the suite.
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.