The first four lessons of this module showed tools: the star, Fabric, the load, Spark. This lesson steps back. Which databases does the Kladde need at all? Who owns the data once it lands in an analysis? How does a deletion reach every copy, including old versions of a Delta table? And what does analytics per office cost? At the end stands the ADR "Analytics for the Kladde" that lesson 4.13.2 announced: read replica, Fabric or nothing for now.
Several databases in moderation
Microsoft's Architecture Center puts it soberly: a single data store rarely serves all access patterns well, and most systems in production use several data models. This is called polyglot persistence. The same guide names the way there, and it does not begin with products:
- Name the application's access patterns: reading by a key, aggregating, full-text search, similarity, time windows, whole files.
- Assign each pattern a data model.
- Only then choose services in Azure that offer that model.
- Evaluate them by consistency, latency, size, governance and cost.
- Combine models only where access patterns or lifecycles clearly diverge.
The fifth point is the most important. It comes with a note from the same guide: a service can offer several models, and then it is better to use the fitting model in it than to combine models in a way that makes operations harder. Azure SQL Database stores not only tables but also JSON, graphs, geospatial data and vectors.
| Access pattern | Model | Services in Azure | At the Kladde |
|---|---|---|---|
| transactions across several rows and tables | relational | Azure SQL Database, Azure Database for PostgreSQL | everything about the business, the event store, the grains' state |
| one document of changing shape, read by key | documents | Azure Cosmos DB | no case so far that does not fit in a JSON column |
| similarity ("tenders like this one") | vectors | Azure SQL (data type vector), Azure AI Search, Azure Cosmos DB |
no case yet; if one comes, first in the existing database |
| many measurements with timestamps, windows over time | time series | Azure Data Explorer, Eventhouse in Fabric | telemetry already lives in Application Insights |
| large amounts of history, aggregation over everything | analytics | Microsoft Fabric, Azure Data Explorer, Azure Databricks | the subject of this module |
Every new data store brings the same list that you worked through module by module in K4: private endpoints and a place in the network (4.7.2), identities and permissions (4.8.5), backup and disaster plan (4.7.5), an entry in the data inventory (4.8.3), a way for access and erasure (4.8.4), cost per office (4.1.5), and knowledge in the team. A data model that the existing database can handle costs none of that a second time.
The same goes for the services from module 4.12. "Data per service" from lesson 4.12.3 gives every service the freedom to choose its store. That is not an obligation to variety: the Tenders service has a database of its own, but the same kind of database as the core.