The growth of PostgreSQL
We are all familiar with Moore's law: the observation that the number of transistors in a dense integrated circuit doubles about every two years. This is as true today as it was when Gordon Moore first made the comment in 1965 when looking generally at the information technology (IT) space. A very interesting parallel observation is the fact that a strong second wave of Open Source is now really rolling in. The surge of PostgreSQL for critical enterprise workloads is hitting enterprises across the globe.
For much of its existence, PostgreSQL has been somewhat hampered in its ability to support some of these critical enterprise challenges. The options for creating an extremely available PostgreSQL architecture, for example, was limited to "4 nines of availability." Although this might sound fairly good—and for most workloads it is good enough—it really is not for some of the most challenging missions.
EDB has been successful in addressing the challenge for extreme availability with PostgreSQL. Introducing BDR (Bi-Directional Replication) into the portfolio of high availability solutions has upped the game, allowing users to meet at least "5 nines of availability" significantly improving PostgreSQL's availability capability. By enabling PostgreSQL to run in a true multi-master cluster configuration, in what is called an “Always On” Architecture, BDR ensures that you will always get a response from your PostgreSQL database. This architecture can be created in multiple availability zones, in multiple data centers, or even geographically distributed depending on your application and data availability requirements.
The most demanding workloads
In the adoption of PostgreSQL, we also see challenges coming from other angles than just mere extreme availability. It is a good thing that PostgreSQL users can now rely on having their data available for at least 99.999% of the time. BDR also provides them with the additional benefit of being able to minimize their database downtime for routine maintenance by enabling rolling updates to their databases.
But some customers and some use cases are even more demanding than that. For certain use cases in the financial technology market and other highly regulated markets, there is a requirement for rigorous controls over the data and transactions that preclude many database management system options. For example, in any applications where there are financial transactions involving very large amounts of money or other “goods,” there is often a requirement for very tight controls and rules for the debit/credit transactions that occur. Due to the nature of networks these days, distributed database systems often need to deal with the complexity of receiving the same instruction over multiple network paths. For these use cases, it is critical that all the transactions are idempotent -- that is, a transaction has the desired effect only once no matter how many times it may be received. EDB's BDR extension to PostgreSQL handles that with with a capability called Commit At Most Once (CAMO) that protects the database from the same transaction accidentally being executed more than once, and thus protecting the database and the companies using them from the potential catastrophic and expensive results of such an error.
This advanced feature of BDR requires some additional changes to the underlying database platform, and these changes are incorporated into an EDB version of PostgreSQL, called EDB Postgres Extended.
Closing the loop on security
Encryption has become a critical requirement for some of these same finserv and regulated market segment companies. One encryption capability of database management systems such Oracle, SQL Server, and DB2 is known as transparent data encryption (TDE) but Postgres does not have native TDE capability. EDB had partnered with Thales to certify that their CipherTrust Transparent Encryption product could be used to protect data that was at rest within both Open Source Postgres and the EDB Postgres Advanced Server implementation of PostgreSQL. With the requirement for EDB Postgres Extended with BDR, we introduced a potential gap in security for our most demanding users for whom encryption was a critical requirement. We are happy to report that the gap has been closed and Thales CipherTrust Encryption has been certified for use with EDB Postgres Extended, giving our BDR users the full data-at-rest protection that Thales offers.
CipherTrust Transparent Encryption secures data at-rest in EDB Postgres Advanced Server and EDB Postgres Extended with file system-level encryption backed by centralized key management, privileged user access controls and detailed data access audit logging. Using Thales’ centralized key management solution, Cipher Trust Manager, customers can efficiently incorporate EnterpriseDB Postgres Advanced Server into their larger organizational security strategy. Privileged user access controls and detailed data access audit logging allow customers to separate security and administrative database duties between teams and increase visibility of the data’s security – both improving the data’s safety and satisfying key compliance requirements. Security admins use these policies to grant specific users access to clear-text data, and to limit the file system commands that they can perform. These access controls establish a layer of separation between systems and data that increases security and visibility of access to the data. Read the solution brief to learn more.
In this way, security teams can permit database administrators to manage configurations and ongoing maintenance on EDB’s Postgres Advanced Server databases without having clear-text access to the sensitive data that resides within.
Check out EDB or Thales for more information about BDR or CipherTrust Data Security Platform.