MySQL Outpacing Oracle In Wake of Acquisition

snydeq writes "Results from the 2010 Eclipse User Survey reveal interesting trends surrounding open source usage and opinions, writes InfoWorld's Savio Rodrigues. Linux usage among developers is on the rise, at the expense of Windows, and MySQL has pulled ahead of Oracle, by a factor of 3-to-2, as the database of choice among Eclipse developers. 'The data demonstrate that fears surrounding Oracle's control over MySQL have not resulted in lower use of MySQL in favor of an alternative open source database,' Rodrigues writes."

Comments

Oh, bruther

[hey!]

What a non-story.

You use Oracle because you *have to*. Not because it is pretty.

Saying MySQL has pulled ahead of Oracle is like saying that claw hammers have pulled ahead of pneumatic hammers mounted on giant excavators.

Re:Oh, bruther

[drinkypoo]

You use Oracle because you *have to*. Not because it is pretty.

Similar things have been said about MySQL. It's a de facto standard, which many view as being quite unfortunate in light of the competition.

Saying MySQL has pulled ahead of Oracle is like saying that claw hammers have pulled ahead of pneumatic hammers mounted on giant excavators.

Since MySQL got clustering it became capable of replacing Oracle in certain contexts. I don't have a tool-related metaphor handy but there are actually cases in which the comparison might not be so ridiculous.

Re:Oh, bruther

[14erCleaner]

Furthermore, this is a survey of Eclipse users, not all database users. Developers using a free framework prefer a free database. Surprise!

Re:Oh, bruther

[Score Whore]

Don't get me wrong, if you write queries that are exactly how Oracle likes them it's fast and solid, but I've worked with SQL Server, PostgreSQL and MySQL as well and the management tools are easier, the query optimizer is more flexible and the error messages more helpful. Particularly that Oracle wants queries their way, I've reused queries that run in seconds on SQL Server and take minutes on Oracle but hardly if ever the other way around.

Treating the database as a black box is the problem, not the solution. At least if you're dealing with more than trivial amounts of data with trivial queries. It is amazing how many developers are shocked that their app, that worked perfectly on their desktop against their own personally installed database with, gosh, nearly two megabytes of data, completely falls over when deployed into against the eight terabyte production database.

In other words, a database isn't a replacement for thinking.

Re:Oh, bruther

[Kjella]

Well doh, that would be comparing blueberries to watermelons. But I've been been working with a product that supports both SQL Server and Oracle so production databases of about equal size, equal hardware and equal content. I develop queries to show something at one client site, then reuse it at a different client site with a different database system. In short, two equally smart database systems should perform about the same. What I'm saying is that in my experience Oracle often generates very poor execution plans, and fiddling with it to make Oracle do it "right" that others manage just fine on their own is not treating it as a black box, it's tedious and unnecessary micromanagement to overcome product shortcomings.

Re:Oh, bruther

[hey!]

For what a lot of people use databases for (backing store for form entry) it really doesn't matter because you only use generic capabilities and work mostly in your IDE.

When it gets to really challenging database problems, it's a question of which fail comes first: the failure of the developer or admin using Oracle or the failure of MySQL to keep up with the application's needs. For example, if you need just a bit more performance, with MySQL your response is simple: get bigger iron. If it's not worth the price, you live with it. With Oracle you start looking into the manuals and contemplating playing with things only an expert Oracle DBA ought to mess with. Then if you get it wrong, it's *your* fail.

I think Oracle's a great product. If I was looking at a project where I had to choose between SQL Server and Oracle, I'd definitely go Oracle even if I had to pay twice the license fee. Oracle's transaction log management capabilities would be worth the price alone. Nobody does transaction isolation better than Oracle, either. But ye gods you can screw yourself messing around on one hand, or not paying enough attention on the other.

I've used both MySQL and Oracle, and I'm comfortable with Oracle, except I don't much like the company or its corporate culture (not that that matters if the question is MySQL vs. Oracle). I might be more comfortable handing off a MySQL project to another developer or manager.

Re:Oh, bruther

[hey!]

MS SQL does a pretty good job optimizing common queries, but at a tremendous cost in orthogonality of T-SQL. I've also found limitations in MS SQL handling of very complex queries, but there is no question that on the kinds of queries that dominate in the vast majority of applications, MS SQL provides reliably good performance out of the box.

That's an engineering trade-off that works for lots of people.

That said, you're going about this the wrong way. The solution to generally inconsistent query performance is database administration, not tweaking. That's "user unfriendly" because it's a job for a DBA, not a user. Oracle gives you much, much more access to the innards of the system, and its stuff that even most tech savvy developers aren't really competent to play with.

Oracle should give comparable performance to MS SQL in most instances without tweaking. Certainly you shouldn't be seeing a difference of 10x in performance that you have to correct by tweaking. My guess is something is really really screwed up on the Oracle installation you were working with.

Finally you also have to evaluate the performance of the query under production conditions, not developer conditions: many large tables simultaneously handling heavy update loads with lots of concurrency issues. The results you are talking about are so screwy, though, it's clear that you've got a really mis-configured system.

Re:Oh, bruther

[hey!]

In short, two equally smart database systems should perform about the same.

Bingo. Ergo, something is wrong with your Oracle installations.

I've done the same, supported an application that is available for MS SQL, Oracle and Sybase Sql Anywhere. MS SQL and Oracle blow SQL Anywhere out of the water in performance, but in most situations you couldn't tell the difference.

From a developer's POV, SQL Anywhere was in most cases a pleasure to work with, Oracle was acceptable in most cases and outstanding in a few, and MS SQL was a horrible PITA. MS SQL doesn't even provide you with a utility to get a human readable dump of the transaction log, much less any way to use the transaction log in a complex recovery (unless you fancy working with page addresses). When a customer does something really stupid, and calls you up saying, "please, please make it like that never happened," it's as easy as rolling off a log in Oracle, practical in SQL Anywhere and not worth doing in MS SQL.

Re:Oh, bruther

[hey!]

Well, one thing I don't like about Oracle is its rapaciously sales-oriented corporate culture. Of course business is all about making sales, but Oracle really doesn't care of you bought the wrong thing or spent 10x what you needed to. They don't care if you buy the wrong class of license and have to throw it away because it doesn't work for you. I've seen cases where organizations have paid huge amounts of money to get Oracle Enterprise where they only intended to use features in Oracle Standard at a tiny fraction of the price. I've seen customers buy per seat licenses, not being informed that that requires a CAL for every computer or device (e.g. phone) that uses Oracle hosted data, then have to pay through the nose for CALs or throw out their CALs and buy a per processor license.

Oracle really doesn't care if you buy something from them that will make you really really mad at them a few months down the line, so long as they have your signature on the dotted line and your money in the bank.

That's not the way customers should be treated. Not if you want them to be loyal.

I'm talking rather of Oracle's technical merits, which are considerable, and in many cases unique. But if you can get away with not using a product's unique abilities, your way better off if you have to port away from it in the future. The same goes for MySQL, which has unique aspects that are not features, per se, but idiosyncrasies. Both Oracle and MySQL are not easy products to port away from, unless you're using really, really common denominator features through some kind of abstraction layer like Hibernate.

Re:Oh, bruther

[bertok]

Thank you! I thought it was just me!

I did the same test a couple of years ago. I was writing an app for a huge data set, but I was told to do the proof-of-concept on both Oracle and SQL Server. I used two identical servers, identical SAN volumes, etc...

The result was shocking. Oracle is at least 5x as slow as SQL Server. It seems to pick acceptable query plans, but for some reason it's just... slower.

One possible explanation that occurred to me is that SQL Server clusters all data by default, whereas that's an optional 'feature' in Oracle. If you try to cluster data in Oracle, it can break other functionality, so it's not the default and developers can't always just turn it on.

Inserting bulk text seems to be awfully slow for some reason as well, and I couldn't figure it out. I saw forum posts along the lines of "well of course it's slow, you're working with text". Meanwhile, SQL Server was doing the exact same thing 50x faster.

Now I don't wonder any more why the Oracle EULA prohibits benchmarking.

Try googling for "Oracle Benchmark". You'll be lucky to find 2 or 3 on the entire internet that compare it to something else, and weren't done by Oracle themselves.

Hey, look

[Megaweapon]

An InfoWorld submitter submits a non-story about Oracle/MySQL on Slashdot. A Slashvertisement for an advertisement.

postgres didn't do so badly

[MagicMerlin]

11%...edging out ms sql server! Postgres 9.0 has built in replication -- it will be interesting to see how that affects its share of the open source db space.

Re:postgres didn't do so badly

[MagicMerlin]

Postgres has traditionally had lousy replication options. This of course is going to change with 9.0 hs/sr. Older versions of postgres (pre 8.x) had some operational difficulties that made it an awkward fit for high transaction load web environments. Now that those downsides are pretty much eliminated, it's about the best general purpose sql database out there -- it has many niceties/features that are rare/non-existent elsewhere. Transactional ddl for example.

Re:Nice to them

[1s44c]

I like Oracle, its products and technologies and I am glad that its opensource products are gaining sales. I wish good luck to Oracle.

I like Oracles's database, it's a great database with tons of features but it's pretty expensive. However the business software that oracle sells is a PITA.

Re:Nice to them

[The Snowman]

I like Oracle, its products and technologies and I am glad that its opensource products are gaining sales. I wish good luck to Oracle.

I like Oracle too, as long as someone else is the DBA. Installing Oracle, setting up a database, and getting it to a usable state is almost impossible without six months of training.

PostgreSQL, MySQL, even SQL Server are all much easier to get up and running in a usable configuration than Oracle. I don't mean slightly easier, either. If other databases are like putting a band-aid on a cut, Oracle is like brain surgery.

The title is misleading

[jitendraharlalka]

It is definitely great to know that MySQL is doing great even in Oracle's hands and even Linux is growing in Eclipse User Survey. However, the title of the post is totally misleading as it is merely based on Eclipse User survey and that too with merely 1696 users. Nearly 40% of the respondents came merely from Germany and France (The survey believes this shouldn't bias result but we really have no reason to believe their assumption).

Re:But what will Oracle do?

[Voulnet]

Lemme take a wild guess.... MSSQL??

Re:Some POed sales guys

[nxtw]

I don't think there are many MySQL users that would have even considered talking to an Oracle sales representative.

Re:State of the Databases

[FlyingGuy]

You could not be more wrong about:

Oracle needs to drop the high prices, the competition in the market now doesnt allow them to have those prices.

An this is why...

It's called support. One of the major reasons I recommend Oracle to clients who need maximum uptime and downtime is just not an option is because of the world class support Oracle provides. If you are a licensed Oracle site you have support 24/7/365 no matter what time zone or country you happen to be in. If you pick up the phone and say those magic words, "I'm down" the calvary is not just coming over the hill they are at your door. Guess what that kind of support costs a lot of money to provide.

In our race to the bottom of the price bucket lots of things have to be cut and guess where they cut first, you guessed it, in support. With Oracle support you do not get script readers in India or the Philippines you get an Oracle engineer on the phone ready to tackle the problem with you until the problem is solved and they will bring in whatever other resources are required.

MySQL is a wonder database that does what it does very well, but would I put it up in a mission critical bit of infrastructure? Not on a bet. Those companies that have, eg: Sales Force and the like have had to hire LOTS of engineers/developers to handle MySQL in big installations and that costs even more.

Postgre has no such level of support either. So when you missions critical DB goes south either you better be able to fix it or you had better have a lot of friends you can wake up in the middle of the night.

Re:Maybe this is why?

[AnonymousClown]

Don't blame the tools for your inability to use them correctly.

That's bullshit and you know it and it's that attitude that gives IT people a reputation of being immature and arrogant .

When I had those problems I googled quite a bit and you know what? The problems I mentioned are very common; which means that it's a design and implementation problem with all of those development tools.

So, I am blaming the tools for their poor design. You can be as condescending and insulting all you want but it doesn't change the fact that the tools have problems.

Re:Nice to them

[jazzkat]

This is because you're using MySQL to develop on. MySQL allows all manner of illegal hostnames and other bad programming practices in the name of "making things easier" for people who don't know any better.

If you developed using Postgres, or another more compliant database, most of these problems would go away.

Re:State of the Databases

[Anne Thwacks]

One of the major reasons I recommend Oracle to clients who need maximum uptime and downtime is just not an option is because of the world class support Oracle provide

If they really need world class support, then they ought to use db2 - its better than Oracle in every dimension, even if you include Larry Ellison's yacht.

If they just need something that works properly, then Postgresql will solve their problems.

Disclaimer: I have frequently been a victim of Oracle since Oracle 5.

Re:Nice to them

[TheRaven64]

Most of the time, people use a database because they care about their data. That's really the point of a database - to provide a persistent store for a load of data that is as difficult as possible to accidentally break. Ideally it should be fast as well, and allow you to access the data in complex ways.

A number of rules in SQL are quite pedantic for precisely this reason. If you enter something invalid then the database could guess what you meant, and might even be right 90% of the time. The other 10% of the time, it would be silently corrupting or destroying parts of your database, or maybe just discarding part of the data that you thought was persistently stored.

MySQL deviates from standard SQL in a number of ways, allowing things that are wrong to do something. Exactly what 'something' is depends on the version of MySQL that you are using.

Basically, using MySQL is like running with a load of error checking disabled. Sure, it's irritating that your code compiled with a load of assert() statements keeps breaking with an assert failure, but generally it's better to see the error and fix it than to deploy a production system after just commenting out the assert() line.