Skip to content
Announcing BigAnimal: Fully managed PostgreSQL in the Cloud
Postgres Build 2021: 30 Nov to 1 Dec
Contact usDocsPlans

Minimizing Complexity in a Polyglot Persistence World

Marc Linster8/3/2017

Data now comes in a wide variety of formats, giving rise to more heterogeneous data collections, often resulting from a commonly employed strategy of choosing the data management solution best suited for the data type and application demands. Selecting the right “horse for the course” approach results in a phenomenon known as polyglot persistence - data assets stored in multiple incongruent formats.

We see environments where an enterprise may use MySQL for capturing events in a web application, Hadoop for storing large amounts of these events over time as well as Internet of Things (IOT) data streams, and JSON storage models for information captured from social applications. 

The simple fact is there are some data management systems that are just better for certain applications. Organizations no longer choose just one type of system and try to force fit all their data/application requirements into it. Instead, they are choosing to deploy multiple data management solutions, each fit-for-purpose to support their business processes. The nature of data as well as operational requirements of the environment needed for modern digital applications are now dictating the underlying data store, not the other way around.

Enterprises need to consider the complexity of polyglot environments when designing their data fabric infrastructure in order to prevent impregnable data silos and to make efficient use of all available data sets including the joining and integration of the data for more effective digital applications. Building systems with polyglot persistence in mind gives enterprises the ability to gain access to data faster, and to shorten time to value. An essential requirement for a polyglot landscape is a structured relational database that allows transactions to be processed appropriately while also integrating with other available data streams. EDB Postgres can be deployed as a standard DBMS for new and modernized applications and can interoperate seamlessly with other new and existing data management systems. In this way, EDB Postgres is well-positioned to play a much more central role in the new polyglot landscape of data.

Foreign data wrappers (FDWs) are the tools EDB Postgres employs for integrating data from different systems. FDWs are an implementation of the SQL standard for Management of External Data (MED). Instead of trying to store all data in one system, enterprises can push, pull and join data in its original native format. EnterpriseDB uses the FDW feature in Postgres to create EDB Postgres Data Adapters. These connect EDB Postgres to external data sources such as MongoDB, MySQL, or Hadoop and can do bidirectional data transfer and joins amongst the data enabling enterprises to work with the data in EDB Postgres, but store it in another system. EDB Postgres can also project relational schema onto the data in the other data stores, and push data from EDB Postgres into those external sources.

For example, EDB has been working with an organization that had over a petabyte of data. In the past, the enterprise would have had to buy an expensive archiving solution. Now, the company need only deploy a Hadoop distributed file system and push the data there as it ages, and use an EDB Postgres FDW that enables them to continue to query the data, even when it’s outside the basic operational set. 

EnterpriseDB® (EDB™) is continuing to innovate and develop Postgres features and functionality to further digital transformation. In the future, EDB Postgres will feature additional capabilities to integrate data such as advanced foreign data wrappers with predicate push-down logic for more efficient distributed processing. Also, users can expect more new data types inside Postgres and faster data integration. And by doing that, EnterpriseDB will be enabling enterprises to advance new digital applications with  greater agility and speed to market.

For more information on how EDB Postgres can support new innovation and digital transformation, contact us at sales@EDBPostgres.com.

Marc Linster, Ph.D., is Senior Vice President, Product Development and Services, at EnterpriseDB.

Marc Linster, Ph.D., is EDB’s Chief Technology Officer. Marc is committed to EDB being an accelerator to providing architectural “know how” to help customers take advantage of Postgres without significant risk and cost. Marc believes that although new customer adoption of open source is easier than ...