ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back 1  2  »  

My advice to the database division at Sun

More and more people are lending advice to the MySQL guys at Sun (not even mentioning the level of fact based slapping its getting along the way). I think there is one important thing missing in this advice, Sun has its feet in 3 RDBMS products: MySQL, Drizzle and PostgreSQL. Even if they paid a 1B USD for the first, the other two are important to remember as well. Actually Drizzle is mentioned a lot in this advice, but PostgreSQL is oddly absent. IMHO MySQL serves a market quite perfectly at this point and I do not see this changing in the next few years.

There are annoyances all around, but the fact of the matter is that we know them well and they do not stop us from succeeding with our web business. Sure proper FK's would be nice, sure non sucking subqueries would make some queries look nicer and yes I guess eventually it would be nice not to hand Oracle business by the way of InnoDB. But even so, isn't Sun a hardware company? So stay as friendly as possible with Oracle and things should continue to work fine (then again my points regarding PostgreSQL might change this). If you have to develop a new storage engine, then keep it at one at a time. Or better yet, scrap the dual licensing scheme on them. As long as you control the kernel what is there to worry about letting the community participate?

So just maintain MySQL, fix all the current features one by one focusing on what web developers need and not what super funkt data warehouse need. Essentially embrace what Percona and OurDelta are doing. They are focusing on adding the necessary instead of trying to please potential future target audiences. You are effectively giving the real world business to others in the hopes of one day getting to tastier budgets.

For that kind of stuff turn to PostgreSQL. Its there, it rocks for this kind of stuff. It fits much better into your hardware business and old school Oracle/DB2 DBA's will have a much easier time to get their heads around it than MySQL. Do not try to make MySQL into something it was never designed to be (intentional or not). Make sure that PostgreSQL continues to learn to scale with as many cores as you give it. Make sure that you leverage all that networking you have in place via your MySQL developers to get the community to understand where they should try to see PostgreSQL as the platform to support.

Now Drizzle. I do not get cloud computing (maybe someone can explain it to me). Its fancy, its hype and I am sure there are plenty of people that need it, next to the other 99% that do not. Maybe this cloud computing thing was just a way to sell the thing to the Sun sales department. Dunno. Most of us today start of with a db installed along with a web server on the same machine. When we need to scale we eventually reluctantly setup a master, but keep a local slave on our web servers. This is todays boring reality. Now if you guys are 100% that in 5 years time we will all do is cloud computing, then make sure that in 2-3 years time we already start using Drizzle for something or chances are that someone else comes along around that timeframe that will do just that and have an installed user base for when cloud computing will really start to make a dent. Either way, plan Drizzle to become the successor of MySQL. Plan to make it a better solution to the needs of web developers in 5 years time than MySQL or other competitors will be in 5 years time.

Oh and on a finally note. Ignoring windows is a bad bad idea and unnecessary (referring to Jay's post here). Every year more and more open source stuff makes its way to native windows versions, so for most (everything?) there are sensible cross platform solutions around. But accept the fact that most web developers are in on windows. Maybe not in 5 years time (ok probably still even then), but definitely in 2-3 years time (the timeframe when you want to build your user base to be able to rule in 5 years).

Ah and a final final note. Forget about this enterprise-community edition confusion stuff. Just focus on being the goto company for support when its time to setup an OSS based database setup (or any database setup for that matter) and have your hardware be the natural combo.


Re: My advice to the database division at Sun

Thanks, Lukas.
This is most sensible advice. Some of it is controversial and it will be difficult to digest/accept, but rest assured that your thinking is not isolated.
There are many people inside the Sun Database Group who are working to change things.
I would love to tell you that I am taking action on most of the things you mentioned, but reality requires some caution and some preparatory work. I haven't got the power of acting instantly on these issues, but I am not letting your voice unheard.
Don't worry if time passes and we seem not to take notice. We care. Please continue giving us advice. We need a fresh view from time to time.



Re: My advice to the database division at Sun

Hi! I particularly like the angle on PostgreSQL.
Indeed, the MySQL products team has been working on its own, however they're no longer the whole of the picture. Within the Sun DB group there are other products to make up that whole, and PostgreSQL is a good part of that.
For instance for GIS tasks, PostgreSQL is much more mature. Now, some people push for MySQL to fix up that slack, but resource-wise it's probably better for the Sun DB group to simply have GIS clients focus on PostgreSQL.

And how about this... some form of integration between MySQL and PostgreSQL, perhaps heterogenous replication or federation?

Anyway, Open Query does PostgreSQL too; I don't pretend to know much about it but we've partnered with Fujitsu Australia. It's a sensible part of the mix, but you don't need to do everything yourself.

Re: My advice to the database division at Sun

Since when has Sun been a hardware company? They haven't had a decent SPARC product offering in about two years. Well, unless you want to spend a million bucks anyway. They couldn't keep pace with Lintel and now they want me to buy a commodity server at Sun prices? Please. Back at the turn of the century when there wasn't a choice, you had to go Sun. But now, I'd prefer my business to grow.

Re: My advice to the database division at Sun

For me a cloud is any deployment where I need to run MySQL with several slaves and my hardware is less than perfect. In that case I don't want to spend all of my time manually setting up new slaves and promoting a slave to replace the failed master.

Re: My advice to the database division at Sun

Indeed, I agree that ignoring Windows would be a guarantee for failure.

BTW, you didn't mention Apache Derby, which is yet another database technology that Sun has worked on.

Overall, I think Sun needs to articulate their database technology vision more clearly, and then work toward that. But that same advice applies to so many companies!

Re: My advice to the database division at Sun


Thinking about a database in a context of "cloud" is not one particular feature. For example authentication, fow should that be done? It should be delegated to a service. Same for logging, etc. Sometimes "being cloud" is just as simple as making it as easy as possible to set up clones of systems or placing sharding in the protocol like we have done.


Re: My advice to the database division at Sun

Quite honestly, I don't agree with you at all about this statement:
"I think there is one important thing missing in this advice, Sun has its feet in 3 RDBMS products: MySQL, Drizzle and PostgreSQL. Even if they paid a 1B USD for the first, the other two are important to remember as well."

There is ABSOLUTELY NO EXCUSE for not being able to do your job. If you can't do your job because of man power, hire more people. If you can't afford to hire more people, do what MySQL did in the beginning: call on the open source community to help. They'd be more than happy to help.

As for the rest of your comments, honestly man I think you're just trying to grab some spotlight attention.

Re: My advice to the database division at Sun

While Sun has blown an enormous amount of money on MySQL, which may have made sense (mind boggles) when times were good and money was plentiful. Now however, especially given the stream of departures from various key developers I can help but wonder if perhaps they should leave the development to the community and focus of providing commercial support services around MySQL in the hope that maybe 10 years from now they can recoup most of the money spent, or at-least slowly write it off.

As a long time MySQL user that had switched over to PostgreSQL in the last 2 years, MySQL just makes me laugh sometimes as a database product. It has a weak/non-existent query optimizer, incredibly shoddy performance when it comes to InnoDB which tries to offer some database features, unreliable replication, etc. For simpler applications like blogs, basic forums and a like I think SQLite is a much better solution and for anything more elaborate PostgreSQL is the answer. While there is probably some room in between SQLite and PostgreSQL that MySQL can occupy, I can't help but wonder its continued existence is largely driven by inertia of past users and that won't last forever.

Re: My advice to the database division at Sun

@Bill: Oh yeah, totally forgot about Derby and is HSQLDB still bundled with OpenOffice?

@Mark/Brian: Ok, its getting clearer to me. So it all boils down to being pluggable I guess. Of course the important bit is that there is enough stuff to plug into. But I guess most of the *nix world is quite prepared to be plugged into easily. Speaking of which, these cloud slaves could really use a good connection pooling solution :)

@Ilia: Well I would not make MySQL out to be that shoddy. It works quite nicely out of the box and it does manage to power a lot of the sites we use. So especially if the focus is put on fixing bugs, I think there is still plenty of life for MySQL in the years to come. Just not indefinitely.

Before you can post a comment please solve the following captcha.

your name:

1  2  »