Related link: http://www.enterprisedb.com
I spoke with Andy Astor, CEO of EnterpriseDB, and got more details on their market strategy for encouraging enterprise adoption of their commercial PostgreSQL bundle.
Their initial push will be focused on providing an alternative to large corporations looking for some relief from Oracle’s steep licensing. Large corporations currently pay the most, and therefore have the most to gain by a viable Oracle work-alike. E-DB’s Oracle emulation currently consists of extensions to the pg/plsql language to support the range of Oracle data types, as well as the input-output parameters.
This seems like a reasonable approach, as Postgres’s sql dialect is pretty close to Oracle’s. But pretty close can still mean very expensive to migrate when you consider a nontrivial database application. To address this, EDB must make it ridiculously easy to port by providing something like 5 9’s Oracle compatibility (and yes I just made that phrase up). But having taken a stab at sql dialect translation, I have to say that I think this is a pretty lofty goal. There are so many corner cases to consider, and the risk of not considering them is that porting to EDB becomes too labor intensive or risky to attempt. Raising the ante even more, EDB’s goal is to do these corner cases not just for Oracle but for SQL Server as well.
As a concrete example, consider running something like OpenACS on EDB. OpenACS is a ~70KLOC open source web appdev framework that currently supports both Postgresql and Oracle. It makes liberal use of packages (not supported in the first EDB release, but ’soon’ in sp1), and of course it uses Intermedia if you want full-text search, and has as least one Java stored procedure that I know about, etc. Any openacs+oracle site considering saving money with EDB would have to address these niggling syntax mismatch issues at the application level, and then do the same for their production support procedures. In other words, people currently using OpenACS in production with Oracle will have to redo their disaster recovery plans, their sql*loader scripts, and plan and execute an extensive regression testing phase for each application being ported. Ouch.
On the Microsoft side, nontechnical challenges present themselves. MS is cleverly pitching their low end SQL Server Express at the price-sensitive part of the market. For $0, you get the same code base they sell for $25k cpu, with limits of 4G/database, 1Gig of RAM, and 1 cpu. If you had to pick a database for Windows and can meet these limits, postgresql/edb is going to be a tough choice for a while.
To be honest, I want EDB to succeed — I would love to give clients the choice to start their app with a free database and upgrade if/when they decide they need to, rather than making a choice based solely on ISV support. And that’s where I ultimately see them being successful: not necessarily in providing a path off Oracle, but in providing a path *to* Oracle. In other words, if your developers learn parts of the Oracle API not supported by EDB, they can code their app to EDB and scale up to Oracle if there’s every a compelling business reason to do so. This option should be very compelling both for start-ups without any legacy app support issues (already prime candidates for open source alternatives) and workgroup applications at Oracle-centric enterprises looking to cut costs and gain some vendor independence.
I believe this is how JBoss initially gained traction with shops who would deploy on commercial java app servers like WebLogic. JBoss provided something simpler, developer friendly, compatible, and way cheaper. At some point, as JBoss matured, people started thinking about the WebLogic deployment phase as optional. For EDB’s sake, let’s hope that history repeats itself.
What do you think EDB needs to succeed? Is the commitment to Redmond and Redwood modes biting off too much?