Polyglot Persistence

I’ve seen the term polyglot persistence floating around Redgate a bit recently in the marketing department. I haven’t really seen this term anywhere, and I wonder if you have. If you have, drop a comment.

The definition is based on the polyglot programming, where you write an app using multiple programming languages. I don’t know a lot of people who do that, and if you do, let me know. I guess some do, since I’ll see things like HTML+C#, or maybe something like Blazor + C#.

In any case, the idea seems to be that you use multiple databases to satisfy your requirements. A few examples might be:

  • SQL Server for most data, Redis to cache shopping carts
  • Oracle for most data, ElasticSearch for full-text searching
  • PostgreSQL for profiles and leaderboards, MongoDB for real-time game actions

I’ve tended to showcase NoSQL + Relational here, but I have seen a few people using two relational stores or two NoSQL stores because it suits their needs. The really common additions (for me) are some type of NoSQL store for performance with more stable, long term data in relational.

I don’t think this covers the relational for OLTP and something else for OLAP/warehousing, as that seems to be an ETL/ELT/transfer of data over time for a different purpose rather than for the same application, but I guess it could cover that.

I think Polyglot Persistence is a good idea, especially when you have complex requirements that aren’t easily solved with one database, even when you have in-memory or search/graph features in your database. Often those don’t perform as well as specialized systems, though there is a level of complexity and the challenge of ELT/ETL’ing the data to/from the second system.

Evaluate carefully, PoC, and test at scale before you decide this is worth the trade.

Unknown's avatar

About way0utwest

Editor, SQLServerCentral
This entry was posted in Blog and tagged , , . Bookmark the permalink.

7 Responses to Polyglot Persistence

  1. dave wentzel's avatar dave wentzel says:

    it most definitely can be OLTP + OLAP/EDW. The absolute most awesome-est architecture would be your application writes via a CEP/CQRS-style interface which then writes to the OLTP + writes to a data lake. The data lake becomes the “hub” in an enterprise service bus -style architecture where anything else that wants to can consume the data offline/near real time via the data lake. An example would be an order is written to kafka/event hub. Immediately it is written to the RDBMS/OLTP. In near real time it is written to the data lake, and a ML algo can pick it up and determine if there are upsell/cross sell oppys (or whatever), etc etc.

    Basically you are using polyglot to write the same data to different datastores, mostly for the reason that those are structured for different use cases (OLTP vs analytics vs ML).

    Like

  2. Dave's avatar Dave says:

    I think I 1st heard it from Martin Fowler (Thoughtworks).

    As described by Martin it made sense. It described an app with its own DB but the DB platform would be chosen for the needs of the app rather than a one-size-fits-all technology choice. It is something that needs careful thought to make sure it is a case where the app/db do form a pair that do behave as a unit.

    I think we need to understand the benefits and compromises involved in polyglot persistence because there are compromises.

    Like

  3. brianary's avatar brianary says:

    I’m not sure if Perl scripts in a batch file is the same kind of thing, but I used that in the ’90s frequently. That often had SQL, HTML, CSS, XML, &c embedded, too.

    Like

    • way0utwest's avatar way0utwest says:

      I think that would be the polyglot programming stuff.

      Perl, I used to be in awe of it. Now I think it’s so un-intuitive and obfuscated compared to Python stuff. Can’t imagine even supporting that code. I’d want it rewritten.

      Like

  4. Drew Morris's avatar Drew Morris says:

    My understanding is that the term refers to multiple storage technologies within a single system.

    Like

Comments are closed.