In 2006, Neal Ford proposed the term polyglot programming. This expresses the idea that software systems may be written with a mix of different languages to get the most significant boost from the best-fit language in a business or technical context. After that, a lot of new programming languages were introduced with the intention of being the best in a specific area, or good in multiple areas.

At the same time, another similar mind-shift happened in the area of data persistence. This caused people to question what would happen if different application parts used different persistence techniques depending on business or technical requirements. For example, storing HTTP sessions for distributed web applications and storing a graph of friends on a social network require different operational characteristics, and consequently require different databases. Nowadays, it is pretty standard for a system to have two or more different database technologies at the same time.

Historically, most Relational Database Management Systems (RDBMSes) are built on the same ACID principles and offer pretty similar SQL dialects for communicating with storage. RDBMSes, in general, are suitable for a wide range of applications, but they rarely have the best performance and operational features for a lot of common use cases (for example, storing graphs, in-memory storage, and distributed storage). In contrast, NoSQL databases that have appeared recently have a broader spectrum of foundational principles, which results in better features for common use cases, even though most NoSQL databases cannot efficiently serve as universal data storage. The following diagram depicts this:

Also, polyglot persistence comes at the additional cost of complexity. Each new storage mechanism introduces new APIs and paradigms to be learned, new client libraries to be developed or adopted, and a new set of standard issues to address in development and production. Also, incorrect use of a NoSQL database may mean a complete redesign of the service. Using the right persistence technology (SQL or NoSQL) should make this more comfortable, but the challenge does not go away.

Spring Framework has separate sub-projects dedicated to data persistence called Spring Data (http://projects.spring.io/spring-data). The rest of this chapter describes different design approaches and database connectors available in Spring Data, especially targeting reactive programming patterns and how they change the way applications access the data stored within a polyglot persistence layer.