EnterpriseDB: A Relational Revolutionary

by Jonah Harris

Related link: http://www.enterprisedb.com/

As a longtime, hardcore PostgreSQL developer, administrator, and
advocate, I was honestly irritated when I first heard of EnterpriseDB
("EDB"). My pessimistic self figured it was another over-hyped
vaporware product and another lame attempt to take advantage of
PostgreSQL's community and BSD license… that all changed after two hours of talking
with Denis Lussier (Co-founder and Chief Architect at EDB).

See, several years ago I started adding Oracle compatibility to
PostgreSQL with a project called NEXTGRES. It's refreshing to see a
company such as EDB expanding on the same idea into fairly uncharted
(yet profitable) waters. Sure, several companies offer products that
translate SQL at the application/driver layer and PL/SQL to Java, but
few have the skill or vision to see the value in adding true blue
Oracle, SQL Server, and DB2 compatibility to the database engine
itself; this is what really sets EDB apart. I know, the next question
you will probably ask is, how is EDB's PostgreSQL-based database going
to compare to Oracle? Here's my answer.

The majority of Oracle users utilize approximately 80% of the features
Oracle database software provides. These users are generally using
Oracle because of PL/SQL (which is without doubt one of the most
powerful, albeit proprietary, database procedural languages), or
because their software vendor requires it. That being said, there
isn't much in terms of actual Oracle features that PostgreSQL can't
technically provide. So you've heard of PostgreSQL, but you don't
know much about it and want to know more.

Unfortunately, PostgreSQL isn't as well-known as MySQL in the open
source database arena. This is largely due to the fact that MySQL is
a smaller-scale pluggable database that requires almost no
configuration or knowledge of the system to install and administer it.
Similarly, MySQL was natively available for Windows much earlier than
PostgreSQL which made it easier for people to download and test.
PostgreSQL, on the other hand, requires you to do a little tuning here
and there and know a little bit about databases. However, PostgreSQL
offers an unparalleled array of enterprise database features and
standards compatibility in the open source database arena. This makes
it more than adequate to start building the additional functionality
most Oracle users require.

What EDB has done is recognize the power and wealth of standards the
PostgreSQL community and software supports. What the EDB folks are
doing is building a compatibility layer ("Redwood" mode) which handles
those features which are most commonly used by Oracle users (including
support of PL/SQL, Oracle data types, and proprietary Oracle functions
like DECODE, NVL, etc.) At the same time, they are looking at a
"Redmond" mode for SQL Server compatibility. Unlike some of the other
vendors, EDB is contributing back to the PostgreSQL community by
providing some funding for the development of the SQL/PSM standard.

My suggestion is that everyone keeps an eye on what EDB is doing;
they're definitely going to turn some heads.


Comments, ideas, and questions are welcomed!