Oracle and MySQL -- Good Move or Bad Bet? 226
sendai-X writes "With the recently announced purchase of Innobase, Oracle has shown it's intention to further support open source. This is key as open source enters the mainstream in business and in light of the success IBM has had with the Eclipse project, and Sun recently looking at purchasing PostgresSQL. What do Slashdot users think about this merger? Is it beneficial to the market and database users by having the largest database vendor openly support MySQL and provide an upgrade path to Oracle? Or is it just another cog in the Oracle machine in their attempt to dominate the enterprise IT market? Will this change the database market landscape? Will it help or hurt IBM and Microsoft?"
Purchase PostgreSQL? (Score:5, Informative)
That would be a neat trick wouldn't it?
They could buy a company that sells Postgres support or makes a version of Postgres that they sell, but they aren't going to be 'buying postgres'. This is may seem like nit picking but it is somewhat important. PostgreSQL is free software in every sense of the term and Sun is not going to buy it. They are not going to purchase control of it.
I guess they could try and hire all the main developers or something. Though I think that'd be tough too. And I'm glad of that as Postgres is my favorite rdbms. I like that it is free and as far as I can tell is going to stay that way for as long as it exists.
Re:Purchase PostgreSQL? (Score:5, Informative)
Right on, yup, that's about the only way they could do that - by hiring Tom Lane or some of the other gurus. But they can't "buy PostgreSQL". There have been some interesting discussions on this on the pgsql-advocacy [postgresql.org] list recently as well.
> And I'm glad of that as Postgres is my favorite rdbms.
Same here! 3.5 million records [blogs.com] and cranking along; PostgreSQL is meeting RubyForge's needs very nicely.
You are referring to MySQL, I take it. (Score:3, Informative)
Sounds like Oracle and InnoDB?
Now about PostgreSQL. It is a community-owned, decentralized project with many copyright owners and contributors. The core community includes developers from the following companies:
Command Prompt, Inc.
PostgreSQL, Inc.
EnterpriseDB
Green Plum
SRA
Afilias
All code is BSD-licensed.
PostgreSQL has a much more vital development community than MySQL...
Re:Purchase PostgreSQL? (Score:5, Informative)
MySQL AB is at the epicenter of development of MySQL DB, and requires copyright transfers for any outside changes. Paid developers at one small company largely create and support the entire database. Some users get a sense of security that there is "one person to go to", and a single focused business behind it. In some ways this business model worked well... their marketing was very successful, and the database might be described as more "unified" than, for example, PostgreSQL, where things like FTS and replication are independently developed (which is actually good, but can confuse users who think that "it's not good enough to be included").
Among the technologies that MySQL licenses from third parties under commercial redistribution licenses:
Berkeley DB (Sleepycat Software)
InnoDB (Oracle, formerly Innobase)
MaxDB (SAP AG)
See the problem? MySQL itself is largely a langauge parser and a simple and technically inadequate storage engine (for anything where data integrity matters). In other words they don't own any of the foundations of their technologies.
Re:Purchase PostgreSQL? (Score:3, Informative)
Consider yourself corrected. I am running a PostgreSQL database with complicated foreign key relationships among tables with millions of rows each. Most of the tables have a couple dozen columns. Joins on these schemas typically involve 5-10 tables. Result sets with appropriate where clauses are typically in the low thousands, but respectable.
These joins usually return instantaneously (or nearly so). I do have some odd cases that can take several seconds to run (and aggregate functions on these sets can take a very long time -- sometimes a couple minutes), but those are not common.
Our main PostgreSQL server handles all the image archiving for 5-6 departments, serves billable data to another primary department (I'm being vague on purpose to appease my boss' desire to not advertise who we are with what we do), serves as the back-end data source for our web server, and seems to just accumulate responsibilities as time goes on.
This is in addition to acting as a file server, internal web server, print server, mail server (not our primary one), and general purpose server as needed. Except for a couple bad warts (very slow aggregates, for example), PostgreSQL has been very good to us.
Re:You are referring to MySQL, I take it. (Score:4, Informative)
I would say that Red Hat employing Tom Lane, one of the most important developers, of PostgreSQL is a serious contribution. Tom Lane's contributions to 8.1 include:
Improve concurrent access to the shared buffer cache
Allow index scans to use an intermediate in-memory bitmap
Automatically use indexes for MIN() and MAX()
EnterpriseDB has claimed to contribute every generally-applicable aspect fo their work back under the BSD license. They have committed to overhauling the stored procedure architecture for the next version in order to offer SQL-99-compliant PSM support.
EnterpriseDB also employes Avaro Harrera who made the following contributions to 8.1:
Move
Add shared row level locks using SELECT
Add dependencies on shared objects, specifically roles
Note that the above issues were just the most major contributions listed in the press release. The 8.1 release represents nearly a year of development by several full-time developers hired by different firms.
But the contributions are not limited to the core source tree. Afilias largely sponsored the Slony-I replication (master/slave with cascade and failover) project by paying Jan Wiek and Chris Browne. Command Prompt released the PL/PHP handler (also open source), PostgreSQL Inc released PGReplicator (though few if anyone still uses this project), and more. My firm is contemplating contributing some table utilities we have developed.
Looking back to 8.0, SRA contributed most of their Powergres Win32 port back in order to get the main codebase working on Windows. This was not a trivial contribution.
Nobody is required to contribute anything back under the BSD license, but in reality it makes a lot of business sense to contribute everything back aside from those that are part of your core differentiation strategy. This is because the community can then maintain it and it is less work for you to merge with future versions. You cannot compete with Free/Open Source in today's economy. So these license wars are just plain silly.
Of course MySQL's main problems have come not from their choice of the GPL but rather from their choice of offering non-Free licenses. PostgreSQL is way ahead of MySQL's functionality despite being of similar ages. This is due in large part to the fact that so many contributions have been made to PostgreSQL by a number of companies. I look forward to the further contributions of Pervasive, Fujitsu, and many others.
When Great Bridge went under, PostgreSQL was not adversely affected. But that was due in large part to the fact that they did not own the core development community. They only had a strong role in that regard. MySQL is more vulnerable to MySQL AB going out fo business, but I think that this is a short-term hazard. Users of non-Free apps requiring MySQL should be very worried, however...
Re:upgrade path to Oracle? (Score:2, Informative)
The sources for the current version are in the GPL - but that is no guarantee that future versions of MySQL (or any other GPL-ed system) have to be released under the GPL. If they have 100% of the copyright they can do anything they want and my understanding is the MySQL have been careful to keep their codebase "clean" so that any external contributions have copyright assigned to MySQL or are simply rewritten.
The GPL ensures that people who use the code with a GPL license have to keep the system "free" but AFAIK it doesn't place any real restrictions on the copyright holders.