If you work with a traditional legacy system, you likely work with a Relational Database. If you work in a Microservice architectural model, you probably work with a NoSQL Database. At some point you probably work with everything in between too. Why does it seem that microservices lean towards the NoSQL or “schema-less” stores, where legacy systems lean towards a relational store?
Legacy
One simple reason legacy systems favor a Relational Database is simply the history of the thing. RDBs were de-facto storage choices for many years. If you needed to store data, you chose one of these things.
On top of that, these databases fit the paradigm of the users of a system very well. Saves are done as kind of big blocks; entire UI pages at once. This change should be visible to everybody immediately afterward. Large, time-consuming work is batched up and executed late at night, when nobody is on the system. Relational databases solve these types of problems very well. ACID transactions ensure consistency. A balance is struck between read and write performance. The UI pages even often reflected the database structure.
As time marched on, these paradigms began to shift. We began to favor more responsive interfaces, which in turn began to drive smaller transactions. We started to be more tolerant of inconsistency, if that meant the thing was more available, or responds faster. Read/Write patterns changed. Times when “nobody is on the system” shrink and eventually disappear.
Problems
In response to these problems, companies desired something that better solved these new pressures. By-and-large, these NoSQL and schema-less solutions solved these problems. They had models that better fit these new tendencies. Consistency was relaxed and availability was promoted. Quick, small changes became the norm. Reads were very fast.
Microservices and these types of databases tend to go together because they tend to solve similar problems.
Disparity
Sometimes, the architecture and data store don’t fit hand-in-hand though. We may desire a microservice approach, for some of the speed and agility benefits that architecture offers. However, maybe the business itself is not tolerant to some of the restrictions NoSQL or schema-less data stores impose. Maybe we just don’t feel the pressures on the data store. Can we mix-and-match?
You obviously have the freedom to mix and match patterns to fit your particular needs. However, this is not an idealistic use of these patterns. Of course, no real system really fits the ideal box for any architecture. Examples will be hard to find. Decisions and trade-offs have to be well explained. In short, you can’t fool yourself for as long as you might otherwise be able to that your architecture fits “this” box.