Blog Update: My original come-on title for this post was a tongue-in-cheek insinuation that EnterpriseDB and PostgreSQL developers have access to Oracle database instances that are not licensed properly and therefore oracle-compatibility in those products would be a form of piracy. I’m probably wrong. I’ll bet EnterpriseDB developers and support folks would never attach to an Oracle instance without paying Oracle license fees and further I’m willing to accept the notion that Oracle would be happy to license a direct competitor to use the Oracle database for reverse engineering purposes. And with that…
In my blog entry about how PostgreSQL is supposedly only 12% slower than Oracle, I focused on the fact that these claims were fundamentally flawed. I encourage you to read that entry for more context.
There is yet another Open Source database called EnterpriseDB that has PostgreSQL at its core. I started digging in to EnterpriseDB just to see what the buzz is. It takes no Google wizardry to find EnterpriseDB making claims to solving problems and saving money. Honestly, I think they get press because of the Open Source phenomenon-or what I call DotCom 2.0 if you get my drift. How can a 2 year old company funded with $28 million venture capital get as much press as these guys? It’s because the term Open Source is involved. Indeed, you don’t hear much about Michael Stonebraker’s company Vertica, which has raised some $16 million in venture capital and is headed by Michael Stonebraker-for crying out loud! Well, I made a blog entry about Vertica back in February, but that doesn’t really count I suppose.
Making Big Waves
Google quickly spits out examples where EnterpriseDB is making waves. For instance, the following articles herald how FTD has managed to move some processing over to EnterpriseDB from Oracle:
That’s all fine and dandy, but I wanted to dig deeper. So, I decided to sit through this webinar presented by FTD and EnterpriseDB. Basically what this webinar spells out is that FTD was reporting against their OLTP Oracle database which was saturating their hardware during their semi-annual peak processing (Valentines Day, Mother’s Day). They needed to off-load the OLTP system so they started looking into solutions. Long story short, they decided to jump past all Oracle products and licensing options (e.g., Standard Editions, etc) and settled on replicating the database to EnterpriseDB and reporting against that database using Oracle Reports. Yep, just tweak a “few” things and slide in JDBC PDS and Oracle Reports is reporting against an EnterpriseDB database. Oh how cool that must seem.
After sitting through that webinar, I downloaded the slides. The one that really caught my eye was:
Odd, what does Sun get by recommending EnterpriseDB into an Oracle shop? Sun was going to get a hardware sale either way, so I don’t get it. In fact, I never understood it when hardware companies recommended one database versus the other. That point seemed weird to me, but that is not what I’m blogging about.
There is one aspect of EnterpriseDB that I want to blog about-Oracle Compatibility. According to EnterpriseDB website, EnterpriseDB is Oracle compatible:
Making the switch from Oracle requires little or no modification to existing applications. Using our Migration Toolkit, the process is often completed in minutes. In fact, our clients report that more than 75% of their applications are 100% compatible, requiring NO changes to run on EnterpriseDB.
Well, the 75% of 100% is nebulous because even he FTD webinar suggested there is more to it than that. In the webinar FTD discussed how they had to:
- Modify RDF file for each report to point to the new database (using the profile created in jdbcpds.conf)
- This is a bit time consuming due to the way Oracle Reports and Reports Builder work -you have to re-point all fields to the new query by hand
There were several things that we had to do to our queries to make them run on EnterpriseDB
- All date operations were modified to use EnterpriseDB/PostgreSQL functions instead of Oracle’s
- All columns that had a string operation performed on them in the query itself had to be explicitly cast to an appropriate size
- ROWNUM references had to be modified to use LIMIT (this is no longer necessary in the new version of EnterpriseDB)
- GROUP BY and ORDER BY statements modified to use column numbers instead of column names (when grouping or ordering by complex columns)
I know shops that have tens of dozens of reports. That seams like some heavy lifting to me depending on the scale of the project. But that is not what I am blogging about.
How Did We Get Here From There?
The question I have is how in the world EnterpriseDB can claim to enhance PostgreSQL providing an even higher level of Oracle compatibility. I’m trying to figure out how one can claim they’ve engineered a product that acts just like another product without having both of them side by side. I know there are very clever (clairvoyant perhaps?) folks out there that can engineer software that mimics other software without doing nasty things like reverse engineering. But does anyone really think that nobody at EnterpriseDB has booted up an instance of Oracle to at least test their claims for compatibility? Moreover, does anyone think that EnterpriseDB can to support software that claims Oracle compatibility without having at least a few servers in their support labs running Oracle?
I just spent some time rummaging through Oracle’s Partner list. I’m probably blind, but I didn’t see EnterpriseDB there. Well, that would be odd since they are trying to directly compete with Oracle-what with selling an Oracle-compatible database and all. Maybe there really are no EnterpriseDB employees that have access to Oracle instances. Maybe.
I don’t think EnterpriseDB is trying to sell and support an Oracle-compatible database without having access to Oracle database software for development, test, and support purposes. And I don’t see them as a member of the Oracle Partner Network. I seriously doubt they cut a PO to purchase licenses, and even if they did, they would be in violation of the EULA because you know for certain you can’t buy Oracle software to help you make software that directly competes with Oracle. So where did they get the software? I suspect they got it from the OTN software download page. Now that is just my suspicion, but if I’m right, they were required to read and acknowledge the license agreement which wouldn’t likely include license to directly compete with Oracle, but I could be naïve. How coincidental, there was a related thread on the oracle-l email list today about using Oracle on VMware and how to license it.
The VMware-related thread centered around the fact that while people wouldn’t use Oracle on VMware for production purposes, they do just fine using it for development and test purposes. At one point during the thread I caught on to the notion that people were just throwing Oracle on VMware instances without concern for Oracle licensing by stating the following:
…this insinuates you don’t see the need to properly license Oracle for development purposes. Am I missing something?
Within minutes there was a post on the list that read:
You don’t need to pay for licences for development systems
“All software downloads are free, and each comes with a Development License that allows you to use full versions of the products only while developing and prototyping your applications.”
I followed up immediately in this post with:
…Oh how I knew people harbor that silly misconception. You have to read the license when you download. That very URL has 2 boxes. One to affirm you are not going to export the software to Libya the other says this:
“You may not:
- use the programs for your own internal data processing or for any commercial or production purposes, or use the programs for any purpose except the development of a single prototype of your application;
[ text deleted]
- continue to develop your application after you have used it for any internal data processing, commercial or production purpose without securing an appropriate license from us, or an Oracle reseller;”
The license for using database software downloaded from OTN allows you to make a single application prototype. Once that application is deployed you have to license it. Further, once that application is deployed you cannot continue to develop it with the downloaded software without proper license. It is right there in black and white.
So how would poor EnterpriseDB get Oracle software so they can continue to develop and support a directly competing database product? Well, they certainly can’t use the bits they downloaded from OTN as I’ve just covered. They could join the Oracle Partner Network.
Well, EnterpriseDB? What’s your OPN number?
I know, I’m probably off base entirely on this one. I doubt EnterpriseDB would have gotten funding from so many venture capital firms to build a house of cards on shifting sand.