In 2006, Neal Ford coined the term "polyglot programming", to express the idea that applications should be written in a mix of languages to take advantage of the fact that different languages are suitable for tackling different problems. Complex applications combine different types of problems, so picking the right language for each job may be more productive than trying to fit all aspects into a single language. This same concept can be applied to databases; so that you can have an application that talks to different databases using each for what they are best at to achieve an end goal, thus giving birth to polyglot persistence.
There are numerous databases out there which solves different problems. Having a single database to solve all of the requirements results in non-performant solution and a "jack of all trades, master of none" situation. For example, data relationships. RDBMS solutions are good at enforcing that relationships exist. To discover a relationship or to find data from different tables that belong to the same object, we can make use of SQL join. This might work when the data is smaller is size. The problem starts when the data grows bigger. A graph database might solve the problem of relationships in case of BigData but it might not solve the problem of transactions which is provided by RDBMS. A NoSQL document database might be able to store your unstructured data to solve that problem. So, we have different problems here which is solved by different databases all from the same application. Simply put, polyglot persistence is to use different data storage technologies to handling varying data storage needs.