EnterpriseDB - competing with giants

From time to time, I have the opportunity to speak with someone from EnterpriseDB, a company devoted to bringing the open source PostgreSQL database to organizations of all sizes. The propose of the call was introducing EnterpriseDB's new Multi-Master Replication (MMR) capability. The conversation then went on to focus on how EnterpriseDB was trying to compete with giants, such as Oracle, to win over decision-makers and database architects.

Multi-Master Replication

EnterpriseDB has long focused on improving the PostgreSQL open source database. The company as worked to improve overall performance, scalability, reliability, security and availability of PostgreSQL. It has also worked to package the open source technology and provide commercial-grade  installation, documentation and support. Multi-Master Replication, now in beta test, is designed to make it possible for geographically disbursed databases to be kept in synchronization with one another.

MMR is trigger based, that is certain events can trigger replication of changed portions of the database to another system in a safe and reliable way. What's different about this version of replication is that systems on both end of the connection can be masters, each running different applications simultaneously. This is a significant improvement over Master/Slave approaches to replication that require a system be devoted to backing up the database system in case there is a need to recover the database after some form of failure.

Oracle, IBM, Microsoft and others have offered replication technology such as this for quite some time. EnterpriseDB's move can be seen either as defensive or as systematically removing barriers to sales to medium and large size customers.

Competing with the giants

EnterpriseDB finds itself competing the giant companies, such as Oracle, IBM, Microsoft and a few others. Over time, the PostgreSQL open source community and EnterpriseDB have extended their technology so that it can address upwards of 90% of the requirements of a database engine to support traditional and new applications. Getting attention and convincing customers to try out the database has been challenging.

EnterpriseDB, and to a large extent, the open source PostgreSQL community has largely focused on the technical requirements of database architects and administrators. When the company speaks about its products and solutions, it tends to speak about the technical aspects of the technology and why it is good enough to be the foundation of today's applications.

Dealing with today's decision process

Unfortunately, companies seldom select a database based solely upon its technical merits.

Application first

If a customer sees its information technology as a necessary evil, it is likely to select applications first, the development tools and application frameworks required by those applications and only then consider which database product is best when supporting that stack of software.

In this case, the database is the third choice and the choice of database is directed by earlier choices.  To win, the database supplier would have to win over the suppliers of both the application and the application development tools/frameworks to even be considered.

I'm not aware of a single application supplier that leads with EnterpriseDB's product or with the PostgreSQL open source project that is the foundation of EnterpriseDB's products and services.

Development tools first

If a customer sees its information technology either as a competitive weapon or as the foundation of its products and services, it is likely that no packaged application software will fit their requirements. So, they'll start with the necessary development tools and application frameworks first, the packaged applications needed to round out their plans for a new product or service offerings.

In this case, the database software is the third choice, once again. As in the other case, the database supplier would have to be recommended by the other suppliers to come to the customer's party.

I'm not aware of a single development tool or application framework supplier that leads with EntepriseDB or PostgreSQL.

Unasked for, shoot from the hip advise to EnterpriseDB

It is clear that EnterpriseDB needs to be more aggressive in winning over other  suppliers to be invited to the customer's application party. Here are some random thoughts on what EnterpriseDB needs to do:

• Demonstrate to suppliers of applications, development tools and application frameworks that they will sell more of their product because the overall solution pricing will be lower than when the same application is sold into the installed base of Oracle, IBM or Microsoft  database users. EnterpriseDB then needs to go on to persuade them to lead with its products in appropriate customer engagements.
  
• Acknowledge that business decision-makers must be won over not just the technical decision-makers. This means that EnterpriseDB must make the business case that its customers saved money, were more profitable and went on to win more business because of their use of EnterpriseDB. EnterpriseDB must then go on to help these decision-makers make the case to company management that an EnterpriseDB decision is not risky.
  
• Rather than always relying on a very technical presentation of EnterpriseDB's merit, it would be best to pick a few important features and show how customers do better because they chose EnterpriseDB rather than products from Oracle, IBM or Microsoft.

This set of comments is only the beginning.

Regardless of the fact that PostgreSQL in general and EnterpriseDB's Postgres Plus are really strong tools and really should be considered, customers must be made aware of the fact that it exists and is available before they'll be interested in learning more. They must be persuaded to be interested in learning more before they'll come to want what the technology can do for them. These customers must want this technology before they can be persuaded to take action and purchase it.