After all, as Charlie Garry-an expert on databases and a former Meta Group Inc. analyst-puts it, many have tried, but none have yet succeeded at making a go of selling PostgreSQL.
In Garrys opinion, he said, MySQL AB holds the key to succeeding in the market for open-source databases. The reason, he said, is that the company doesnt rely on community input to the same degree that PostgreSQL-wannabes such as EnterpriseDB do.
"The difference here is that with MySQL the company is the only developer of core functionality," Garry said. "They control the product roadmap and act as the source for the definitive version of the software. That is (in my opinion) what makes MySQL the one to watch."
EDB CEO Andy Astor said this lack of input strikes him as a matter of some concern. "The whole idea of open-source software is that an open community identifies the direction it should go," he wrote in an e-mail exchange.
"Thats what the PostgreSQL community does, and EDB is adding additional capabilities for a specific market segment. The underlying direction from the community is actually missing from MySQL."
With regards to EDBs trying what has failed for others-i.e., commercializing PostgreSQL-Astor said that EDB is not marketing PostgreSQL per se, but instead is adding functions to the PostgreSQL code base such as Oracle compatibility and performance enhancements.
"EDB is based on PostgreSQL, but it has a significant value-add on top of it," he said. Those who have tried to market PostgreSQL-Pervasive, Red Hat and Great Bridge-marketed pretty much plain old PostgreSQL, Astor said, adding only an installer and a few tuning capabilities.
With regards to MySQLs oft-lamented lack of enterprise features, Garry said its of no consequence. "Since it would take years of triple-digit growth within the data center for an open-source database to make a significant dent in the database market, MySQL has years to acquire the core functionality it will need," he said. "Switching costs for databases are high; if they werent, I doubt Oracle [would be] No. 1 today."
The community itself, meanwhile, is reacting with a mixture of indifference and defensiveness, with some members unaware of the level of contact thats already occurred between EDB and the community.
"To be honest, no one seems to really care too much," wrote Christopher Kings-Lynne-a PostgreSQL developer and lead programmer for Family Health Network Pty Ltd., a company that specializes in online weight loss programs in Australia and the United States-in an e-mail exchange. "Its obviously great, but [EnterpriseDB doesnt] seem to have contacted the development team, or proposed funding development or anything like that."
Meanwhile, PostgreSQL developer Robert Treat, writing on the new PostgreSQL blogs site, initially said that the release of EDB convinced him that the PostgreSQL project is forking, with segments of the community marching to their own drummers.
"Not in the classic sense; there werent any flame wars by core members and no big march of a bunch of developers to leave the project," he wrote. "But we certainly have a couple of forks running around, even though they might not be advertising themselves as such."
Specifically, Treat recently noticed talk about table partitioning within PostgreSQL on both the "pgsql-hackers" list and the "bizgres" list. He replied to the pgsql-hackers thread to mention this fact.
"This led to a little bit of a Why are [we] discussing PostgreSQL features over there when we do development over here? [discussion]," he said. "A valid question, though no big deal on its own. However, the bizgres folks are also talking about having their own release schedule, so that they can get table partitioning to the market ASAP even if PostgreSQL core isnt ready to go with it, and that could certainly lead to divergent code bases."
Treat mentions another example of forking thats resulting in feature work being duplicated: "EnterpriseDB lists one of their compatibility enhancements as allowing column-based triggers in PostgreSQL, which is something that 8.0.x doesnt have."
The problem, Treat wrote, is that the same enhancement is being worked on for Version 8.1. "So now Im curious what EnterpriseDB has coded up, and when (or if) it will be donated back to PostgreSQL core, and why they might think it is a good thing to have people doing duplicate work on a feature?" Treat wrote. "And heres hoping those features dont end up syntactically different!"
For his part, Treat wrote, he prefers the way Pervasive is going about commercializing the PostgreSQL code base, although even that company has made more smoke than fire.
"They have made too many big, splashy claims, and havent contributed any big batches of code, but they have offered up support with some back-end hardware for PostgreSQL Web folks, and so far they are keeping in step with the PostgreSQL core projects releases," he said.
"This just seems better for the project, which is really just hitting its stride, and doesnt need any more confusion about what features are included where."
In a response to Treats blog, Astor wrote that EDB has "no intention of forking to create a de facto new database" out of PostgreSQL.
"Indeed, we consider it a required core competency for us to be able to merge anything we do with the latest release," he said. "To wit, we launched yesterday and are running on 8.0.3. Furthermore, we intend to contribute our work to the community after a reasonable return on investment. I know, I know ... exactly what does that mean??? We dont know precisely ... it depends on market acceptance and the communitys interest in accepting it.
"But suffice it to say that we are working hard to ensure that the features we implement are technically aligned with how the community would approach the same work, to the extent that the community might take on that work. ... Obviously, Im asking you to take our word for it. ... But thats all I can do, actually. So, please try to give us the benefit of the doubt."
Another point worth noting, Astor wrote in his exchange with eWEEK.com, is that wherever EDB is working on issues simultaneously with the community, including triggers and I/O parameters, EDB will endeavor to ensure that the work is complementary as opposed to duplicate.
Meanwhile, in the main code base, "remarkable" new features are being worked on or have already been completed for the next release, said Kings-Lynne, including two-phase commit, shared row locks, horizontal table partitioning, IN, OUT and INOUT parameters to procedures, and bitmapped indexes.
Editors Note: This story was updated to include input from Andy Astor.