Datadog’s recent research captures a reality many teams already feel in practice: once companies move to microservices, their database landscape tends to fragment quickly. Based on data from more than 2.5 million services, Datadog found that more than half of organizations use three or more database technologies, about a quarter use five or more, and nearly half run SQL and NoSQL side by side.
That trend makes sense at scale. Different services have different workloads, and large organizations often have enough platform maturity to support multiple storage models. But the same pattern is much harder to justify in small companies. In many cases, teams adopt several databases not because the business truly needs them, but because microservices make local decisions easier than system-wide ones.
The result is a familiar architectural trade-off. Teams gain service autonomy, but they lose data simplicity.
In a monolith, the shared database is often a bottleneck for team independence. Schema changes require coordination, coupling grows over time, and one database has to satisfy many use cases. But there is also a major upside: joins, referential integrity, and transactional consistency stay close to the data. Complex business questions can often be answered inside one engine.
Microservices change that. As Datadog puts it, organizations replace one global schema with hundreds or even thousands of smaller schemas owned by individual services. That improves isolation, but it also makes cross-domain queries harder. Customer data lives in one place, orders in another, payments somewhere else, and support history in yet another store. The business still needs a unified view, but the data is no longer naturally unified.
This is where many teams discover that the join never disappeared. It just moved up the stack.
Datadog points to GraphQL as one way organizations handle this problem. Instead of joining data inside a relational database, they assemble it in an integration layer that queries multiple services and data stores behind a single schema. That works, but it comes with real cost. According to Datadog, 55% of GraphQL executions include more than 10 child resolve spans, and some services handle more than 100 resolves per execution. The median graphql.execute lasts about 200 ms, while individual field resolutions are closer to 40 ms, showing how query depth and resolver fan-out add latency even when work is parallelized.
This is an important architectural point. A database join and a distributed join are not equivalent. A relational database resolves joins close to the data, inside one execution engine. A GraphQL layer has to orchestrate calls across service boundaries, manage partial failures, control N+1 query behavior, and hide inconsistent latency from the client. It can be done well, but it is undeniably more complex.
For small companies, that complexity is often disproportionate. A team with limited platform capacity now has to operate multiple databases, maintain integration logic, and solve analytics separately. Datadog notes that analytics becomes harder in microservice environments because data from distributed systems has to be transformed and consolidated into OLAP platforms such as Snowflake, Redshift, Databricks, BigQuery, or ClickHouse; 44% of organizations in their data already use at least one such platform. Service integration gets harder too, which helps explain why nearly 70% of customers use message queues to decouple services asynchronously.
None of this means microservices are a mistake. It means they should not automatically lead to polyglot persistence. For a smaller company, a standard relational database plus a small number of carefully justified supporting technologies is often the better choice. PostgreSQL for transactional data, Redis for caching, Kafka only when event streaming is truly needed—this is usually easier to scale organizationally than letting every service pick its own storage engine.
The main lesson from Datadog’s research is not that using many databases is modern. It is that fragmentation has become common, and common is not the same as optimal. Large companies may benefit from specialized databases because they have the scale, workloads, and platform teams to support them. Smaller companies often inherit the downside first: more schemas, harder joins, more integration layers, and more operational surface area.
So the practical question is not whether a service could choose its own database. It is whether the organization can afford the data integration problem that follows.
If the answer depends on GraphQL layers, resolver batching, warehouses, queues, and custom aggregation logic, then the cost of database diversity is already showing up. At that point, the simplest architecture may not be the most fashionable one. It may be the one with fewer databases.
Source: Datadog, How microservice architectures have shaped the usage of database technologies.
Top comments (0)