SAMP?

A few articles making predictions for 2008 had put an initial public offering by MySQL on their list. The company had clearly been heading in that direction for a while; sales were growing, venture capital was coming in, etc. In the end, though, the MySQL IPO seems destined not to happen - Sun Microsystems got there first. The deal is structured as a full acquisition - Sun will pay about $800 million for all outstanding shares of MySQL stock. In addition, about $200 million in options will be covered, so, overall, this is a billion-dollar deal. Not bad for a company which is based on free software.

Sun is making the right noises about how this deal will work. There is no talk of taking MySQL proprietary or changing its license. MySQL will continue to be supported on all platforms, and not just Solaris. A series of grants will be made to help university researchers advance the state of the art in database management systems. There is a lot of talk about continuing to support "the community," though details are (perhaps necessarily) scarce. CEO Jonathan Schwartz says that Sun will be working to improve "the rest of the LAMP" stack, though he says nothing about the "L" (for Linux) part.

Chances are that this deal will be a good thing for MySQL users. Sun is clearly making MySQL an important part of its overall strategy (in these days, one does not toss $1 billion toward unimportant objectives) and can be expected to continue - or accelerate - development of the system. Sun's free software orientation is strong enough that the chances of parts or all of MySQL going proprietary seem small. Indeed, nothing in Sun's releases says anything about MySQL's commercial licensing business; the emphasis appears to be strongly on support and services. So MySQL might just become even more open than it is now.

Sun appears to be positioning itself to compete strongly with Oracle. Both companies are working hard to be able to offer the entire software stack to their customers. So Oracle's push into the Linux distribution business and Sun's database venture are both aimed at having the same story for their sales staff to tell: we, in some way, own and control all of the software you are looking to run. No problems with incompatibilities, finger-pointing, etc. As an added bonus, Sun will happily sell you the hardware you need too. Do expect an increase in efforts aimed at moving MySQL users away from the (Oracle-owned) InnoDB engine, though.

For Sun to sell that story, though, it will to have continue to push Solaris hard as an alternative to Linux. Either that, or the company will eventually find itself shopping for a Linux distributor of its own. Either way, it seems likely that competitive pressures for operating systems (and higher layers) sales and support are set to increase, especially in the high-performance web server area. Red Hat, whose PostgreSQL-based database offering appears to have fallen below the radar, may find itself scrambling for a response.

Sun makes a big point of being able to sell the entire package, and there is some truth to that. Processors, storage, systems software, database software, programming languages, office suites, and more can all be had from one company. What remains to be seen is whether this is really what customers want. There is a lot of value in being able to integrate components from multiple sources and not being dependent on a single vendor. Your editor, who managed a transition from being an all-DEC shop to an all-Sun shop some twenty years ago, is not convinced that those days are worth going back to.

---

(Log in to post comments)

With MySQL, it always seems like they are going to have some feature in the future, or got it,
ran into trouble with it, and are going to rip it out and reimplement it in the future.  With
PostgreSQL, it always seems like the feature has been stable for years and they are busy
enhancing it.

MySQL always seems like the "just you wait" RDBMS whereas PostgreSQL seems more the "come and
get it" RDBMS.

Except where it comes to marketing.  There, MySQL has it all over PostgreSQL.    May the best
marketing team win!  Good for MySQL and MySQL AB.  Bad for OSS RDBMSs.  

Oh well, I do administration on both PostgreSQL ans MySQL servers. And to tell you the truth,
yes, PostgreSQL seems more feature-complete, but MySQL is still my favourite for reasons:
Usability (as in administration easiness) and availability of choices.
Usability includes the way I can do replication. With PostgreSQL, the only real choice I have
there is using external programs. With MySQL, I can even have two servers replicate from each
other as long as I make sure that no database (actually table) is written to from both
machines at the same time. And the setup for this is dead simple.
Choices include the tradeoff between ACID compliance versus database speed. I use (as most do)
MyISAM for speed where I don't need ACID compliance and INNOdb where I need it. I can't do a
similar thing with PostgreSQL to the best of my knowledge.
Mind you, I still have application for which PostgreSQL is the better choice. Ironically, this
historically included commercial, closed-source apps for licensing reasons (that might have
changed since I last checked).

What I really can't hear anymore is the constant MySQL bashing from certain PostgreSQL
supporters. Both RDBMSs have their strengths and shortcomings. There is no better OS RDBMS,
there might be a better OS RDBMS for a specific problem.

regards,
Sven

Unfortunately, MyISAM is still default for new tables, so unless you add "engine=InnoDB" at
table creation time, you will be using ISAM.

(While we are at it, for the readers who would like to switch:
“If you want all your (non-system) tables to be created as InnoDB tables, you can simply add
the line default-storage-engine=innodb to the [mysqld] section of your server option file.”)

I'm very wary of how this thing might end up.

The crucial question to be asked IMHO is why they bought it? Excuse my slashdot joke, but
didn't they see the "download" button? 

Now, jokes apart, I fear that Sun will try to use mySQL to push its solaris-based enterprise
solutions and in doing so, they might create problems to the Linux port of the RDBMS. In other
words, up to now mySQL worked better under Linux, now it'll work better under Solaris.

And that's the best case scenario really. Screwing it like they did with other projects they
got their hands in and making it complicated to configure is another scenario.

One thing is sure. mySQL was a relatively small's company only product - with all the care a
small company's only product gets - and this now changes and puts mySQL into a giant
corporation's range of tools. This can't be a change for the better anyway you see it

> Only product?
You're wrong there. 
Of databases, they have MySQL, and MaxDB.
Beyond that, they have a number of closed-source management apps for dealing with the above.

MaxDB aka. SAP DB is a complete POS, I've spent years using it and the only good thing I ever
did with it was to drop it and move to Postgresql.

The internals of MaxDB consists of tons of pascal files that have highly cryptic (german!!!)
names and it has clearly seen better days.

Performance is awful and mostly single threaded as it uses locking to ensure serialization
rather than multi version concurrency.

In short: Don't touch MaxDB with a ten foot pole, except if it's to push it into a volcano.

> The internals of MaxDB consists of tons of pascal files that have highly 
> cryptic (german!!!) names and it has clearly seen better days.

I can't make a judgement on the code quality of MaxDB, but "german!!!" file names?

Dear English native speakers, have you ever wasted a second thinking about speakers of other
languages who need to adapt to your language all day long to write a single line of code?

English is the No. 1 language of the Computer Age, sure. I write 99% of my codee with English
names for functions, variables, and files. But bashing a software just because it uses
non-English names is a bit Anglo-centric.

I'm not a native english speaker, I'm from Denmark, a little country bordering Germany:)

Choosing some other language than english for code is generally a bad idea because it will
make it harder for just about everybody to work on the code.

Sure it would be nice if everybody could just learn every other language on earth, but that's
just not going to happen.

Choosing German names for code is just as bad a mistake as basing a new system on COBOL, not
because German or COBOL are horrible languages, but because both choices will limit the number
of developers that can work on the code.

For reference I had several years worth of German in school and I have glanced at COBOL
listings, both experiences make me happy I don't have to use either language today.