EnterpriseDB - on the road to federated, collaborating databases

Martin Banks Profile picture for user mbanks February 4, 2016
EnterpriseDB’s new Advanced Server 9.5 may be 'just another upgrade', but it also points to a way of building collaborative database management environments that map into the wider world of collaborating applications and services.

Clouds above road
Stories about the latest version of 'Product X' can be a tad yawn-provoking unless the reader is an avid and deeply committed user of said product already. And even then this may be the case, as many such users have already been beta testing the upgrade for the last few months. Sometimes, however, something comes along as part of an upgrade that may just point at something a bit more significant.

One such is the latest upgrade – Version 9.5 – of the EnterpriseDB Advanced Server, which includes some new tooling that points in an interesting direction – the ability for users to build federated databases, bringing together different databases from different vendors into collaborative collectives that can serve the needs of the bigger, more comprehensive business services that are now starting to appear.

What arguably gives this notion a bit more gravitas is the fact that EnterpriseDB is no start up suggesting that major corporates commit their database infrastructure to some new and untested whizzo technology.

As the company’s CEO Ed Boyajian pointed out, EnterpriseDB has had a goodly amount of success, particularly over the last three to four years, in penetrating the legacy enterprise market with its open-source, Postgres-based, SQL database:

If you looked across our customer base today you’d see something like 87 of the fortune 500 are our customers and I think that’s a telling statistic for the success of EDB Postgres adoption. Postgres was designed actually from the same technical whitepaper, the system-R Whitepaper, that was used as the foundation for the creation of Oracle and DB2. So Postgres, Oracle and DB2 could all have the same theoretical roots from a technology perspective.

He now points to some of the largest financial services companies, such as ABN, AMRO and MasterCard as customers, and not just dabbling with pilot projects.

Even databases must collaborate

This combination of a solid technology underpinning, growing enterprise credibility and a changing marketplace - where the growing need for collaborative services is changing the rules for current `owners’ of large swathes of the incumbent technology - looks like it could move EnterpriseDB a good be closer to `festival mainstage headliner’ status.

The other component in this the natural cost advantages of open source products, even if they come in the form of a paid-for, branded distribution, such as the company’s Advanced Server. And the saving is not to be sniffed at, here. According to Boyajian, this comes out at around 10% the cost of a typical Oracle equivalent. As a reference point, he quotes the list price of Oracle per core as being $47,500. The Advance Server list per core is $1,700, while acknowledging that there can be many pricing variables that come into play between `list price’ and the final invoice.

It is the changing marketplace, however, which is the key element and one where the latest Advance Server 9.5 could help to develop a different way of looking at databases as an integral front line component of new collaborative services.

One of the biggest strengths of the growing number of the new tools being used to build cloud-based services is their capability to build extensive, collaborative services, where multiple applications collaborate together to create increasingly complex business services. The question EnterpriseDB is starting to address is whether there is a role within such a scenario for having the databases collaborate?

The answer is becoming a more likely 'yes' as databases serving the newer, often customer- or partner-facing applications have to integrate with established back office systems, such as existing Oracle databases serving out a long and hard-working lifecycle on largely highly structured datasets. With some of those new databases servicing, and even running, short lifecycle applications generating unstructured or oddly structured data, that old and new mix will make it increasingly difficult for businesses to build the essential `one version of the truth’ that represents their business.

Taking small(ish) steps for now

There is still some way to go before that becomes a reality, but while for many applications APIs are becoming the 'lingua franca' between them for building collaborative services, Boyajian suggests that getting there for database systems will involve the company in more than just creating appropriate APIs:

We’re taking advantage of some unique attributes within Postgres in terms of the ability to handle data outside a traditional database and we do that, basically, through data connectors. We use a mechanism within Postgres called Foreign Data Wrappers, which allow us to connect to non-Postgres databases and to be able to interact with those databases in their native state. We have been building that FDW capability most recently with data connectors to MongoDB and Hadoop.

As larger customers redefine their infrastructure the company is starting to see large customer environments where Postgres exists alongside other databases, working as part of an integrated system. He suggests that the FDW connectors now allow Postgres to act as a hub in such an ecosystem:

This now makes sense to most of our customers because the primary activity is where most of the transactions are taking place, and that is in the operational database. We think of that as the OLTP system of record. So these data connectors allow us to talk to Hadoop, to talk to Mongo and operate in a data federation model. There are others that can do things similarly but I think Postgres has done this uniquely well and I would say, from an Open Source perspective, we lead in this category.

In the here and now, Boyajian sees this capability as the way to penetrate into the established Oracle marketplace. Oracle already has a well-integrated set of tools and applications, including Oracle 12c, Oracle RAC and Oracle NoSQL Database, as well as an Oracle Hadoop Database. In the Open Source world, he argues, all of those parts exist, but they don’t all connect, and building that integration capability is where he sees EnterpriseDB fitting right now.

But he is aware of the potential it also carries for building richer, more comprehensive levels of federation between different databases:

What is so intriguing about the data management category as it relates to Open Source is it’s really in the earliest stages of a massive change. Traditionally, customers have control of their data, theoretically, but the vendors have control of their wallet. Open Source breaks that chain. That then gives them control of their data and control of their wallet. That’s why Open Source technology, beyond the innovation and all the other things that people love about it, are the hallmarks of why in large enterprises, why everybody, wants to move to Open Source.

As we look forward we’re going to continue to build up these capabilities that surround the Postgres database and allow that to operate successfully in these new heterogeneous data environments. We’ve got a few examples in this release but they’re pointers to where we’re headed.

My take

This seems like another good example of how the purview of what constitutes a technology – in this case databases – is having to stretch and grow outside traditional boundaries as the scope and complexities of business processes grow. That means collaboration between applications of all types is now the name of the game, so much so that applications which `stand apart’ will be at a disadvantage unless there are ways in which they can be included. It appears this is what EnterpriseDB is really pitching at.


Disclosure - at time of writing, Oracle is a premier partner of diginomica.

A grey colored placeholder image