Time and again, I meet customers who are so used to a certain Relational Database product, that for them a concept is synonymous to the specific implementation of the concept. Over time, the proprietary players have sown the seed in our brains and have nourished them with tutorials and documentations and we tend to believe that a certain method is the only way of achieving something. Or in worst cases, I have seen customers asking for a feature rather than asking for a solution for their requirement.
Quite often, I meet customers who ask for RAC implementation or equivalent in Postgres. Well, RAC is not a feature but is actually an implementation of High Availability cluster with Load Balancing. Today not only we have many more solutions to match what RAC offers but such solutions have become a little irrelevant.
Now what I hear from customers is, RAC helps them scale horizontally. They can have a single copy of database and still scale up on computing and memory of another machine. But with more and more datacentres getting virtualized and 64-bit architectures pushing their way through, this is hardly an advantage. Virtualization allows one to add more resources vertically on the fly and 64-bit architecture has taken away the limitations we had on memory that can be attached to one node. Not to forget, RAC comes with its own complications and resource requirements for interconnect and global cache.
On engaging further with customers I realize that in most of the cases all they need is a high availability cluster or to put it simply redundancy of nodes. To customers who like to stick to a shared disk architecture, I suggest to go for Red Hat Cluster Suite.
Very few of these customers have load distribution and High Availability requirements at the same time. In most of these discussions, the concluding remark is that one does not really need such a costly and over-engineered solution to achieve scalability and high availability. PostgreSQL, which is recognised as the most advanced open source Relational Database, Has an in-built replication solution called Streaming Replication. Streaming Replication helps you create a replica using WAL (transaction log) replication.
Oh, I forgot that some Oracle RAC users are big fan of transparent JDBC driver for load balancing. Well there is another open source product called pgpool-II, which does this for you. pgpool-II will handle load distribution of read queries as well as the task of directing write queries to Master Node.
We still need a cluster management tool for managing auto-failover for PostgreSQL database. Well this is where companies like EnterpriseDB come into play. They innovate continuously so that the great open source projects become a part of reliable enterprise class solutions. EnterpriseDB also provides a tool – EDB Failover Manager which can help manage such clusters, provide a floating IP and automate the failover and promotion.
So in-practice your Shared-Disk Active-Active Clusters e.g. Oracle RAC can be replaced with a much less complicated setup using Streaming Replication feature of PostgreSQL which is far more cost-effective too! Here is how ARIN replaced their Oracle RAC environment with a similar setup in PostgreSQL. Get a glimpse of how easy it is to setup and manage, in this Google Hangout event conducted by us last week.
Write to us if this tinkles a bell in your head. We specialize in such setups and can help you, save your spending on Database licence without having to compromise on scalability and reliability of your environment.

Other content in the Newsletter:

What is the most important asset of the organisation – It’s the people – Sachin Dabir
All this (deluge of) Data – is it really impacting our life? – Deepti Dilip
Video Interview: Talking to Ed Boyajian, CEO and President of EnterpriseDB