The inside scoop on EnterpriseDB

Just over a year ago I wrote a quick entry on EnterpriseDB and their entry into the DB market as an Oracle replacement. I've been in contact with them as of late to determine if my small shop could unload some of it's high Oracle costs onto their database. After a pretty decent phone call yesterday, the sales engineer sent me the following email (the name has been changed to protect the innocent).

So far it's pretty intriguing, but I've got a few concerns:
1) it (support) still isn't as cheap as MySQL
2) adoption rate
3) it's really only been around for a year and a half

Some other notes:
- Their clustering technology "GridSQL" is still beta, expect it to be out later in the year
- The sales folks weren't obnoxious and the sales engineer guy knew his stuff and answered all my questions without hesitation
- They support Hierarchical queries, although missing some features like "connect_by_root" this really helps me out quite a bit

Without further ado, here is the email...Until next time...Rich

-----Original Message-----
From: joe []
Sent: Friday, September 28, 2007 7:16 AM
To: Richard Murnane
Subject: Re: the inside scoop on EnterpriseDB

The documentation at will get you started with our command line client, this page will help you in connecting as well as how to list tables, indexes, etc....

As a note, all of our documentation is searchable (via a google appliance) at

As for a list of utilities, we don't have anything official, but here's a few to get you started:

The EnterpriseDB server is owned by a non-root, operating system user (for security reasons). This user has exclusive access to the data directory and is therefore the only user that can control services. You may control services as root using the /etc/init.d/edb_8.2 script (it actually does an 'su' under the covers and issues start/stop commands as the 'enterprisedb' user).

A note on layout. EnterpriseDB is a different from oracle in how it uses files on disk, I'll give you a quick overview, and please feel free to ask questions. Basically, instead of getting a small number of data files like Oracle, EnterpriseDB has a data directory. This directory is known as a 'cluster',, every cluster consists of one and only one data directory, and a data directory consists of one and only one cluster. A cluster is capable of supporting multiple databases (I'm not actually aware if there is a limit or not here), and cluster gets its own tcp/ip port on the network, so you could have one cluster, with 5 databases on port 5444, and another cluster with 2 databases on port 5445, etc...

A cluster is/has:
One and only one data directory
A group of databases
A dedicated tcp/ip port
Its own backend processes (1 process per connection + 2 or 3 system processes)

All of the relations (tables, indexes, etc...) are stored in the 'base' directory under the data directory; basically, as a relation grows the file grows with it, however once it reaches 1 GB in size, a new file is created. Therefore, a 5 GB table would have at least 5-1 GB files associated with it on the filesystem. You don't need to worry about managing this in any way, as it is all handled by the storage manager.

Again, if you have questions, please feel free to ask.

exp: pg_dump / pg_dumpall
imp: pg_restore
sqlplus: edb-psql
lsnrctl: The EnterpriseDB listener is invoked automatically when the service is started, there is no separate piece, however, controlling services may be done in a number of ways:
pg_ctl: This is an executable that will take the [start | stop | restart ] options and control the server. See pg_ctl --help for more options.
(Must be run as 'enterprisedb' os user)

/etc/init.d/edb_8.2 [ start | stop | restart ]: This provides a method for root to control the server. Depending on your OS and version, you may be able to use this script as a non-root user if you have the 'enterprisedb' user's password.

Note; A difference from oracle, when you start the server using one of the above methods, the server is started and databases mounted, there is no need to connect an issue 'startup'. Once you have received a successful start message, you are ready to begin processing connections and transactions.

The primary configuration file is: /opt/EnterpriseDB/8.2/data/postgresql.conf

Since our Dynamic tuning agent will automatically tune the most important settings for you (you can change the amount of resources that dynatune will use via the 'edb_utilization' parameter in that file; a 100 means that you have a dedicated server, 66 means that it should be considered a shared server, 33 means it should be a developement box and 0 turns it off.

If you are curious about any of the other configuration parameters, you can use the documentation, or feel free to contact myself or

As I said before, if there is anything that I can do to assist you in your evaluation, I'm available on email and at the phone numbers listed in my signature.



Popular Posts