MySQL Founder Starts Open Database Alliance, Plans Refactoring

Gary Pendergast writes "Monty Widenius, the 'father' of MySQL, has created the the Open Database Alliance, with the aim of becoming the industry hub for the MySQL open source database. He wants to unify all MySQL-related development and services, providing a potential solution to the fragmentation and uncertainty facing the communities, businesses and technical experts involved with MySQL, following the news of the Oracle acquisition of Sun." Related to this, an anonymous reader writes that "MySQL has announced a project to refactor MySQL to be a more Drizzle-like database." Update: 05/14 20:50 GMT by T : Original headline implied that this was a project of Sun, but (thanks to the open source nature of MySQL) it's actually Monty Widenius — no longer with Sun — leading this effort.

Comments

PostgreSQL

[Anonymous Coward]

Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.

Re:PostgreSQL

[glwtta]

In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.

That actually sounds like it plays into one of the MySQL talking points a little bit, so I want to assure all the MySQL+PHP developers out there that you won't have to - you might anyway, but you won't have to.

Re:PostgreSQL

[umeboshi]

There was an april fools joke around here a couple of years ago.

http://developers.slashdot.org/article.pl?sid=07/04/01/1448207

Perhaps it's time that this approach should be realized, instead of just joked about. This would allow people to to use the mysql api for their applications that require it, while providing a path to start using postgresql in the future.

Re:PostgreSQL

[Anonymous Coward]

why the hell was this modded informative?

this is one of the silliest things I have read in days.

it should be +5 funny
not +5 informative.

Re:PostgreSQL

[kris]

It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.

Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.

What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.

Re:PostgreSQL

[|DeN|niS]

Slony-I is asynchronous. Read postgres' excellent documentation for some other possibilities.

You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.

Re:PostgreSQL

[nicklott]

Ah yes, but you're forgetting that postgre is advocated by smug holier-than-thou geeks, the kind that everyone wants to punch in the face. This means that it will continue to be an obscure footnote in database history, while mysql continues to be the world's most widely used database.

Re:PostgreSQL

[Anonymous Coward]

Yes. And Slony is also difficult to administer and easy to break.

Postgres is very much lacking a simple replication solution. If you're in the cloud, it's far more likely you're going to have many many smaller database spread across many machines. You need to be able to bring up groups of 3 (minimum) machines that cluster an entire database quickly and easily. You don't need all the flexibility of Slony, and you certainly don't need it's administration headaches.

I can't even imagine trying to administer 10's of databases with Slony, not to even think about 100's or more.

Re:PostgreSQL

[Anonymous Coward]

why the hell was this modded informative?

Because it is informative.

this is one of the silliest things I have read in days.

In other words, you neither know nor read much.

it should be +5 funny
not +5 informative.

Informative is precisely what it is.

Funny is what you are.

Re:PostgreSQL

[coreb]

It is already being done.

Re:PostgreSQL

[Slashdot Parent]

Slony-I is a dreadful hack that misuses triggers, and doesn't scale past a few nodes.

I'm sorry, but Slony-I is not a serious replication solution.

Re:PostgreSQL

[ShieldW0lf]

The reason MySQL is able to scale in that fashion is because it doesn't respect the integrity of your data. If you're building an application where occasional corruption is acceptable, that's all well and good, but if you need your database to be properly ACID compliant and still scale, you've got a more difficult task to deal with, one that MySQL doesn't even attempt. They made their compromises.

Skype seems to be having a lot of success scaling out PostgreSQL.

http://highscalability.com/skype-plans-postgresql-scale-1-billion-users

It's a shame that Monty has always been inclined to obfuscate these issues in the name of gathering market share for his little toy... personally, I don't trust him any further than I could throw him. He's got no integrity whatsoever...

Re:PostgreSQL

[Anonymous Coward]

> You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master?

more flexibility than what? MySQL's replication allows all of the above.

Re:PostgreSQL

[CarpetShark]

I'm sorry, but Slony-I is not a serious replication solution.

I believe the PostgreSQL devs themselves have said as much (officially, on their site). They've also said that the reason for this situation is that the project had previously taken the stance that it should not include its own replication, but should instead allow third-parties to implement replication as they see fit.

However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct, built-in support for basic replication, as well as making sure that heavyweight, third-party replication solutions are still supported.

Either way, I don't think these replication issues are a good enough reason to use MySQL instead. Worst case scenario, there ARE good replication options for PostgreSQL. There are even third-party products out there that can replicate from Oracle to PostgreSQL. Interestingly, that particular solution was targeted at MySQL first, as it has similar issues.

Re:PostgreSQL

[Slashdot Parent]

However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct, built-in support for basic replication, as well as making sure that heavyweight, third-party replication solutions are still supported.

Well, wake me when it's there. MySQL still gets bashed for its historical lack of transactions, so if Postgres wants credit for something, it can at least implement it. Last I checked, it was supposed to be in 8.4, then it wasn't, then it was supposed to be in 8.5, and if memory serves, it's slipping again.

Either way, I don't think these replication issues are a good enough reason to use MySQL instead. Worst case scenario, there ARE good replication options for PostgreSQL.

So which one of those solutions is:

1. Easy to configure (as in, no harder than MySQL replication).
2. Scales linearly (Slony-I scales quadratically, which is why you can't get beyond a few nodes)
3. Can add a slave node without downtime
4. Can handle, gracefully, a failure of the master node
5. Can do master-master replication
6. Can do statement-based replication and also log-based replication (to support autogenerated keys, rand(), etc.)

MySQL replication supports all of the above, and has for years now. Postgres has some serious catching up to do in this area.

Re:PostgreSQL

[dave87656]

We ported our DB to Postgres and never regretted it. MySQL is good for read only apps (such as web applications) but it isn't well suited to transaction oriented apps. Postgresql is faster and more reliable.

Yes, but....

[djupedal]

Did you go out there and talk to the Oracle? Did the Oracle come out into the sunlight and say anything at all...any gestures, groans, wild waving of hands, rolling of eyeballs...anything?

Can we go out and talk to the Oracle in person?

Dammit man, time is running out - we must speak to the Oracle....now, not later, right now!!!!

Re:Yes, but....

[Ilgaz]

I don't get why they treat Oracle like AOL acquiring Netscape. It is a database development company which has no solution to fill MySQL'es place if I haven't mistaken.

I think after these incidents, large companies will think 1 billion times when they got the idea of acquiring an open source project. They treat Oracle like AOL for God's sake.

Re:Yes, but....

[Korin43]

I thought Oracle was a database? Is it different enough from MySQL to bother keeping both?

Re:Yes, but....

[DragonWriter]

It is a database development company which has no solution to fill MySQL'es place if I haven't mistaken.

Oracle has a number of lighter DB products, including Oracle Express Edition (XE) which is free (as in beer). They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does, but certainly they have a number of products whose market niches at least overlap with that of MySQL.

(Also, Oracle is a lot more than a database development company and has certainly been more aggressively pushing into other areas; I suspect that their acquisition of Sun was more focussed on the non-MySQL parts of Sun than on MySQL.)

Re:Yes, but....

[Doctor Faustus]

They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does
Regular Oracle tables and index-organized tables have completely different physical implementations, and bitmap indexes have a completely different physical implementation from regular indexes. They're all ACID, though.

Re:Yes, but....

[Anonymous Coward]

Just figured I'd bring up here that since they've stated they plan to keep SPARC R&D going, maybe one of their big goals is to retain processor independence, while also leveraging an architecture that better coincides with their probable workloads (Sun's biggest feature has always been IO throughput and reliability and with their highly multithreaded chips they would seem to mesh well for the large scale databases that they'll be pushing.)

Re:Yes, but....

[Ilgaz]

OK but none of the products gets hit because MySQL exists right? So, is there any reason other than insanity to undermine/conspire/kill MySQL? They act like there is fire in house and Oracle is the mad guy who started it. Did any of these people attempted to contact Oracle a single time relating to the future and independence of MySQL development?

Guess what will small companies choose if there is image of a chaos/forking rather than a known brand like Oracle when they hear MySQL name? Do you know the evil monopoly company who sells 400 dollar bulky Office products successfully in the age of 2009? Yes, they will win and as side effect, their OS monopoly will gain even more ground. All serves to them at the end, somehow.

Re:Yes, but....

[Anonymous Coward]

Oracle has a number of lighter DB products, including Oracle Express Edition (XE) which is shit (as in poop).

FTFY.

Re:Yes, but....

[DragonWriter]

OK but none of the products gets hit because MySQL exists right?

Since they have overlapping niches, probably some of Oracle's products, particularly at the low end, take a hit from MySQL. Since even their free low-end products are designed to be compatible with and provide an upgrade path to their pricier DB offerings while its probably as easy to go from MySQL to PostgreSQL-based EnterpriseDB, DB2, or MS SQL as from MySQL to Oracle, their certainly might be reasons why they'd rather, over the long term, either phase MySQL out or evolve it into something very different than it is now. They might not, too; its fairly popular, does have a commercial presence which (I assume) is profitable, and may bring enough to be worth keeping around even if it hurts sales of other Oracle products.

Re:Yes, but....

[larry bagina]

MySQL isn't a database.

Re:Yes, but....

[Dragonslicer]

I thought Oracle was a database? Is it different enough from MySQL to bother keeping both?

If you have to ask that question, just believe us when we answer "Yes."

Re:Yes, but....

[spauldo]

Freightliners and Vespas are both vehicles.

Oracle is what you use if you have hundreds of millions of dollars, a team of DBAs, and your need for data storage is such that downtime is measured in thousands of dollars lost per minute.

MySQL is what you use if you've got ten employees (one of which knows a bit of PHP) and sell motorcycle parts over the internet and you don't feel like an ebay store would quite meet your need.

They're both great products (I assume, I'm not a DBA and haven't messed with oracle). They're both RDBMS's. They both run on just about any modern platform. They're not used for the same stuff.

Re:Yes, but....

[Anonymous Coward]

Yep! Oracle bought out Sleepycat that was once a backend (one of the bigger ones) for MySQL, just to see what would happen. They then swallowed up one or two more back ends, just to kill them (they aren't even offered as products anymore). Sleepycat wasn't a big database, in fact very very small. Oracle wants MySQL dead. Don't be confused. It hurts their bottom line. 20 million database driven websites would be forced to something else if MySQL was dead. Fortunately MySQL is at least partly GPL. I couldn't give a rats ass about what a commercial company wants. I know what I want! I'm willing to contribute to MySQL, so long as I get a stake in its long-term future. GPL and this project is that guarantee. Depending on Oracle is going the way of the Swammy. One day he's here, the next day, he's on the magic carpet gone back to the far unknown. Sun bought MySQL. Sun got bought by Oracle. Oracle didn't buy MySQL. Sun for a while tried to Fork MySQL. That backfired. Oracle WANTS TO KILL IT! They can't, but the commercial side of it they can. A fork is probably the best thing that can happen right now. Oracle can't prevent a fork, and even if the project forks, I still expect commercial support for MySQL (from Oracle) to go away very soon. That they haven't shut it down or 'merged' it at ungodly prices yet is a bit of a surprise, although its only been a few weeks. The ink isn't dry yet.

Re:Yes, but....

[vegiVamp]

Yeah. Oracle doesn't run all that well on the less-than-16-gig market.

Re:Yes, but....

[Anonymous Coward]

So do I mod this +1, Car Analogy, or -1, Car Analogy?

More on topic: MySQL is also what you use if you're Google, Yahoo, Facebook, or Wikipedia, and you want to massively scale out without spending tens (or even hundreds) of millions of $MONETARY_UNIT to do it.

As for Mr Widenius' recent shenanigans, I think the proper response is, "Excuse me, Monty, but could you please explain what part of You sold it, and therefore it's not yours anymore it is that you fail to understand?"

But then, this is a guy who uses "family-oriented business" to mean "an operation small enough that I can micro-manage or ignore any aspect of it as the mood strikes me, make or break the rules on a whim, blame others for not fixing bugs that I myself marked WONTFIX years ago, bask in the glow of my own mini-Cult Of Personality, and in general behave fairly irresponsibly".

I'm waiting to see what happens when Sun and Oracle -- both of which have FOSS database offerings -- express an interest in joining the ODA's little party... :)

Re:Yes, but....

[Anonymous Coward]

The problem is that Oracle has sold its database solution to businesses that don't have a need for it.
What businesses really need to spend so much on Oracle and to have entire teams of DBAs?

Let me tell you ... really few.
It promises the sort of pie in the sky solution to businesses that overestimate their needs and would be better off with Mysql / Postgresql or even SQL Server (if open-source scares them).

This can be an analogy to Japanese cars which seriously threatened the U.S. automobile industry ... cheap, reliable, getting the job done. Many people just realized that's all they need.

Not to mention that MySql scales better horizontally. This is the reason a former employer, a big software company you definitely heard about, is switching to Mysql from Oracle.

Oracle and Mysql are direct competitors, whether you realize it or not. Not complementary, but competing. And Mysql is also free. And for technical support you can choose Oracle or the team formed as we speak by the Mysql founder that's gathering previous Mysql devs under one roof.

Re:Yes, but....

[Zarluk]

Why troll? He's right!

Re:Yes, but....

[Zarluk]

They're both RDBMS's.

No, they are not! MySQL is NOT a RDBMS. No transactions, no integrety validations, just indexed tables wrapped by a SQL dialect!

Re:Yes, but....

[spauldo]

Looked at it since the 3.x days?

It's got transactions, and has had for quite some time, depending which backend you use. Integrity validations can mean a lot of different things, but it's got quite a few of them, especially since 5.x. It also supports several different backends, not just the old table formats it did ten years ago.

None of these things are part of the definitions of an RDBMS anyway (except perhaps the table thing, but even that is splitting hairs) - they're just standard features most RDBMS's have. It does manage relational databases, and (to most of us) that makes it an RDBMS.

Re:Yes, but....

[Anonymous Coward]

About a decade or so after buying RDB (from memory) Oracle Corp still develop and support it.

Can anyone name a product that Oracle Corp bought and killed?

Its worth looking at past behaviour, it won't predict the future but it may show a trend ...

Refactoring Eh?

[Anonymous Coward]

I do that when I write shitty code too.

YAY!!!!

[davidsyes]

FORKIN' AYE!!!

This should be a GOOD thing, and hopefully it will move FAST, be stable, and be not politically hamstrung.

Re:YAY!!!!

[Ilgaz]

If they don't come up with a pure technical reason, a proof for forking the project rather than "big company hate" or conspiracy theories, they are already taking this decision politically.

If they think Oracle purchased Sun just to kill their project for 7.2 billion dollars in such state of Global economy, they are bordering megalomania.

Re:YAY!!!!

[idontgno]

See also Amiga Persecution Complex.

Re:YAY!!!!

[Nutria]

If they don't come up with a pure technical reason, a proof for forking the project rather than "big company hate" or conspiracy theories, they are already taking this decision politically.

Why can't it just be that they have finally admitted that MySQL really sucks at anything but simple queries.

What they should do is start anew with the PostgreSQL codebase. It already has an Oracle "skin", so why not a MySQL "skin"

Re:YAY!!!!

[Ilgaz]

As a former Amiga user and one of OS/2 Victims, I really know that complex very well. It could be the reason why I think twice before bad mouthing any other company rather than the product/code in question itself.

Re:YAY!!!!

[gbjbaanb]

Its never what you think of the state of today, its what you think it'll be like tomorrow. As a result, no-one cares that Oracle bought MySQL, they care what Oracle will do with it - and a lack of vocal support usually means no interest in it.

As a result, the fork is a very pragmatic solution, get it forked today, get some impetus and media interest in it, and either Oracle will come out and confirm its continued support; or you'll know where to go to get MySQLv2.

And Oracle bought Sun for Solaris, I reckon they don't give 2 figs for MySQL.

Fo Shizzle

[0100010001010011]

Myizzle SQL be-izzle lizzleke Drizzle.

why?

[Lord Ender]

For apps that need basic SQL functionality and aren't particularly-high load, I use SQLite. For app that need advanced SQL or high load, I use Postgres. I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).

Re:why?

[Reality Master 201]

Existing products - there's some software packages people like to use from the open source world that are tied to MySQL.

But yeah, if I had any choice, there'd be no instances in which I'd pick MySQL over SQLite or Postgres.

Re:why?

[Lord Ender]

WHY use MySQL? Gee, because it's well documented,

That's certainly a good thing, i'll give you that.

it plays nicely with Perl and PHP,

I just threw up. As my keyboard shorted in its vomit bath, it outputted a random string of characters and symbols, which just happen to execute without warnings when piped to perl.

Re:why?

[Anonymous Coward]

What about Postgres can't play well with Perl? What do you think the point of DBI is?

If you have corporate hosting that won't let you install whatever you want, get a better host.

There's a ton of MySQL websites because everyone is struggling to make MySQL do anything useful.

Re:why?

[chickenandporn]

Many of us MySQL users see your Postgres question the same way: why use Postgres? There's 10 users of Postgres, and if I randomly toss both names into a room, I don't have to explain what MySQL is. Hell, half think I said "postfix" and leave the room.

What's MS SQL? OK, I'm kidding, but it makes me wonder if you've checked MySQL lately. I haven't had a reason to check Postgres, so I maybe just-as-satisfied with MySQL as you are with Postgres.

MySQL works for many of us. We don't want to switch to a different database in this tier of performance/cost. Plus, it's well-known outside of its fan-base, and is supported by a host of servers.

I'm not inviting a Postgres-vs-the-world fight here, I'm pragmatic, and the one that works and has better compatibility TODAY is MySQL. Maybe next year, that'll be Postgres among the circles I work in. Today, that tier is held by MySQL, smaller to SQLite, and larger to Oracle.

Re:why?

[johannesg]

Every fucking time there's a MySQL article, you Postgres trolls come out of the woodwork. Give it a fucking rest, already. We're talking about MySQL, not your beloved Postgres.

Fair enough. However...

WHY use MySQL? Gee, because it's well documented, ..., there's good documentation and websites, etc etc etc. You can't say the same for Postgres.

That's bullshit. The PostgreSQL is among the very best I've ever seen for any piece of software, open- or closed source. And I've seen _lots_ of it...

Re:why?

[DragonWriter]

WHY use MySQL? Gee, because it's well documented, it plays nicely with Perl and PHP, it's available on nearly every corporate hosting package, there's good documentation and websites, etc etc etc. You can't say the same for Postgres.

IME, you can pretty much say all of that for Postgres, Postgres "official" documentation and third-party "how-to" information, on the web, in dead trees, and otherwise, is as good, or better, than MySQL documentation (though the total volume is somewhat lower, the coverage and quality seems equally good or better), Postgres plays very nicely with scripting languages (though I've used it with Ruby far more than Perl or PHP); the only advantage I see to MySQL on the points you make is that there are somewhat fewer hosting packages that offer PostgreSQL.

Re:why?

[Daniel_Staal]

MySQL is not well documented. It's got horrible documentation. Granted, it's got lots of it (and everything is there somewhere), but it's all horrible: Specifics of syntax and usage are often spread through half-dozen pages for a single command, with no linkage between them in the HTML.

As for 'playing nicely'... You've obviously never tried to get the Perl DBI working with MySQL on RedHat. As far as I can tell, the process is 'Recompile it. All of it. Again.' I spent two weeks trying to get it to work. Our scripts (that have to work with MySQL) currently output to a temp file and then run that via a call to shell.

I'll give you 'available on nearly every hosting package'. But then, so is Windows.

Re:why?

[Lord Ender]

MySQL works for many of us.

I didn't ask if it worked. I asked in what scenario it would be a superior option (to the well-informed application architect, of course). The only real reason you gave is that you don't know much about Postgres. That means you're not really qualified to answer the question.

Does it scale better? Does it have better security? Is it easier to manage in some way? Is there a killer feature its two closest competitors lack? Those might be actual answers to the question. "I don't know much about it" is not an answer.

It's certainly commonly perceived that Postgres will scale better, and that it has a rather complete featureset. If this is indeed the case, I can't see a reason to select MySQL for a new project. Why limit yourself?

Re:why?

[TypoNAM]

This is one major reason why I refuse to use PostgreSQL: VACUUME for the fail.

Why the hell do we have to hand hold PostgreSQL to get it to clean up after its self? MySQL has no problem doing it on its own nor does any other databases that I know of require such an operation. Its also quite lame to run a dedicated daemon to monitor and tell PostgreSQL to clean up its mess. Another thing which was a past problem was the user permissions were just terribly implemented making it a complete joke to use for multi-user environments. Now it does appear that was resolved.

The reason why I really have such a huge problem with VACUUM is that there is just no way in hell that a user program could ever know a good time to issue the cleaning procedure, that should be the database's job, not the user program period because it won't ever know about all the transactions going on and so forth. Imagine if the Linux kernel required root to issue some commands to have the kernel clean up after cache handling messes every once in a while to ensure continuing operation of the operating system and then a couple years later the devs figured creating a dedicated daemon to automate the command issuing tasks would be sufficient... it just doesn't make sense.

Re:why?

[rho]

MySQL is well documented so that all the bugs are turned into features:

Mein Broder: So, in MySQL, when you exceed the maximum size of a TEXT column, does it throw an exception, or does it just truncate the data to fit?

Me: Well, it being MySQL, it will probably do something differently on Tuesdays than it does on the vernal equinox... but it probably will throw an exception and bitch about how you suck at data planning. Which is the proper thing to do, because who would want their database silently truncating data?

Mein Broder: In this case, I'd actually prefer it, 'cause otherwise I'd have to programmatically truncate it myself. These data aren't really that important, and truncating would be acceptable. It would be nice if I could be a lazy programmer.

Me: I think you're out of luck. But let's take a look:

MySQL Manual -- If you assign a value to a BLOB or TEXT column that exceeds the column type's maximum length, the value is truncated to fit.

Me: Astounding. Your desire to be a lazy, shiftless programmer has been facilitated by other lazy, shiftless programmers who have built the world's most rickety database management system.

Re:why?

[Anonymous Coward]

Maybe you should have followed your link:

"Fortunately, The Auto-Vacuum Daemon monitors table activity and performs VACUUMs when necessary. This eliminates the need for administrators to worry about disk space recovery in all but the most unusual cases."

Re:why?

[Daniel_Staal]

You'll be glad to hear about the autovacuum built into PostgreSQL versions 8.1+. (Ok, so it's not on by default yet. One configuration switch.)

I could give you the good reasons for having VACUUM run separately, (Actually, it's often easier to know from outside when your database is going to be busy...), but in general I agree having to run VACUUM was a pain. I'm glad it's no longer needed.

Re:why?

[vadim_t]

Actually, VACUUM has been automatic for a few years now. The dedicated daemon has gone away too and been merged into the server process.

And sometimes it may make sense to manually scheduling VACUUM. For instance if you never delete from a table there's no need to bother trying to vacuum it. If you have a very high load, it may make sense to defer it until a low load time. It also makes sense to manually run it after making big changes to the database (like restoring a backup for instance).

But in current releases it works fine on its own and there's no need to mess with it unless you have a special need for it.

Re:why?

[Lord Ender]

I imagine the intent is for database administrators to issue that command during scheduled maintenance windows. I agree that an "auto vacuum" feature would be preferable for many people. Is "auto vacuum" the major advantage of MySQL over Postgres, then?

Re:why?

[theshowmecanuck]

Is sounds like you are saying that because it gets a lot of press causing a lot of people to know the name, then it must be the best database server out there. And it is more compatible and works better because of that? WTF? What the hell do you mean by compatible by the way?

More people know or knew how to program in Visual Basic than in Java or C or C++. Does that mean it is a better programming language and more compatible? You are going to tell me that what I just wrote doesn't make sense. And you would be correct. But neither did your statement. I also used Visual Basic as an example on purpose. Being popular doesn't make it the best, and using the most popular tool doesn't make the best programmer and subsequently the best code.

Both databases have JDBC and ODBC drivers, meaning both can be accessed by business systems requiring an RDBMS. They both use SQL, granted both have variations in the SQL statements as do all RDMBSs (but this should be a non-issue for new development as the differences are not great).

There is one area I think will differ greatly, and that is in database/schema design. Most/many MySQL-Java shops I have seen have poor database designs, especially when the Java programmers rely too heavily on Hibernate to create the design, which is almost always. I think Hibernate is a good tool if used appropriately, but there are too many cases of people using ORM ONLY to create their database, and don't think about the database design any other way. This leads to very poor and inefficient database design. Even at my present company, a high tech start up where much of the server side code and databases where built this way. The databases are now dragging their MySQL asses now that the volume of data is increasing. Not necessarily because of it being MySQL, but because the use of ORM ONLY to create the database design. I'm not saying that this can't happen in a Postgres shop, but I normally see more deliberate database designing where Postgres is used. Perhaps because it isn't quite as light weight it may require better designers to use it, which leads to better database designs. Similar to how C and C++ require more highly trained and deliberate programmers than Java in order to produce good code.

Flame on!

Re:why?

[Eponymous Coward]

MySQL is better because I know how to use it and it works well enough. If I were to switch to Postgres, then I would have to spend time learning it.

My manager would rather me move some other feature forward rather than replace database A with database B.

When we hire somebody new, it is easier to find candidates who already know MySQL. That matters too.

-ec

Re:why?

[chickenandporn]

Maybe I misread your post -- you were asking why we don't change from MySQL to Postgres, since MySQL is the default server in most cases.

You were also converting a question about MySQL into an argument of "Postgres vs MySQL"; I was trying to explain why we don't change to Postgres. See, change-to-Postgres is an important part: there's no obvious benefit that outweighs the cost of changing. The cost of changing is also the cost of changing all of our dependencies to use Postgres.

So "why don't we change to Postgres?" Because it works, it's wellknown (we don't have to explain it), it has more compatibilities in the products our areas use.

Better than Postgres? Who cares? Maybe it is. We haven't had a reason to consider that, we're too busy getting to work, getting things done. p.I don't expect you to read this far; I expect you to take apart small subtle spelling mistakes, but you can take my lack of response to mean "hey, he's working, rather than wasting time debating bike shed paint colour options"

Re:why?

[JackARot]

Maybe I misread your post -- you were asking why we don't change from MySQL to Postgres, since MySQL is the default server in most cases.

You seem to be barely able to read since that's not what he said at all. He said:

For app that need advanced SQL or high load, I use Postgres. I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).

No where in there does it ask why people aren't switching over. He was saying he can't imagine a scenario for why he would choose MySQL over Postgres.

Re:why?

[Anonymous Coward]

I'm going to state something controversial, but for many applications security doesn't belong in the database, just like business logic. I would say this applies to most new web based applications developed today with ORM tools like Hibernate, but as always, there are exceptions.

MySQL's killer functionality is the ability to plug in different database engines. So, for example, MySQL can be both a transactional database with InnoDB and a column based database with Infobright.

Both are good, but I would say MySQL (with drizzle in particular) is focusing on the future of databases in the cloud and Postgres is focused on replicating the functionality of databases designed for corporate environments. Both are important environments and will remain so for quite some time.

Re:why?

[chickenandporn]

It's an interesting question then; the situations I see are the opposite: MySQL is the compatible solution already functioning, and a user would have to choose to change to Postgres.

Hey ("barely able to read"), thanks for being childish. It adds humour.

Re:why?

[JackARot]

It's an interesting question then; the situations I see are the opposite: MySQL is the compatible solution already functioning, and a user would have to choose to change to Postgres.

Change what? You still seem to be unable to comprehend what he said. He was saying that if he was writing a new app that required a SQL database that he can't see any reason to choose MySQL over Postgres. Where are you seeing anything about changing databases? And secondly how is Postgres not a compatible solution that already functions? In what way is it either incompatible or nonfunctional?

Hey ("barely able to read"), thanks for being childish. It adds humour.

Well considering how you seem to be unable to comprehend basic English sentences one has to question your ability (or inability as it seems) to read.

Re:why?

[Hognoxious]

What's the most negative number MySQL can store?

I'm asking because that's your score at reading comprehension.

Re:why?

[mzs]

Look-up a bunch of cheap hosting providers. How many have postgres? How many have mysql? See why you might choose mysql over postgres (or db2 or sysbase or oracle) for non-technical reasons?

Re:why?

[JackARot]

Look-up a bunch of cheap hosting providers. How many have postgres? How many have mysql?

You do realize that it's not just web apps that use databases right?

See why you might choose mysql over postgres (or db2 or sysbase or oracle) for non-technical reasons?

No, I just see a reason not to use a cheap hosting provider.

Re:why?

[Anonymous Coward]

I was actually involved in the decision at my business to switch from Postgresql to MySQL, and documentation ended up being the deciding factor. Now I've been using Postgresql personally and professionally for years, and I love the database, but two days with the documentation for the various clustering / replication sub-projects was enough to make my brain hemmorage. It's like they took legitimate documentation in some language, randomly truncated one sentence every other paragraph, and then ran the whole thing through a series of babelfish translations before posting it to the web. Compare that with the MySQL online documentation and numerous third-party publications and you end up hard pressed to argue for Postgresql once you reach the boundaries of your experience and need to rely on published documents to move forward in a timely fashion.

Re:why?

[drinkypoo]

I just threw up. As my keyboard shorted in its vomit bath, it outputted a random string of characters and symbols, which just happen to execute without warnings when piped to perl.

Is the new slashcode out already?

Re:why?

[bmartin]

I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).

I work for a Fortune 500 company. We use MySQL with J2EE and Hibernate in a production environment. Postgres would be our fall-back option if MySQL ever stopped doing the trick for us, but it scales well to thousands of users.

MySQL can easily be configured for use as a production-quality database. We also use Oracle and DB2 on an i5 for certain purposes, but our biggest app (in terms of company scope and $$) employs MySQL in the back-end.

That's why :-P

Re:why?

[DragonWriter]

Look-up a bunch of cheap hosting providers. How many have postgres?

Fewer than offer MySQL, but enough that if PostgreSQL is the right DB choice for technical reasons, this just means you don't choose one of the hosting providers that don't support PostgreSQL, not that you choose MySQL.

(Assuming, of course, that you are building a web app where a discount shared hosting service is the right choice to start with; of course, not all apps for which a DB is needed are web apps, and not all web apps are those for which a discount shared hosting service makes good sense.)

But, sure, if you are artificially constrained to choose from one of set of hosting providers, none of which offer PostgreSQL and some of which offer MySQL, that's certainly a reason to choose MySQL. But that sounds like a result of a bad planning process, not something that should ever occur in the implementation of a new application.

Re:why?

[transwarp]

I just read the Postgres manual page another Slashdotter pointed to, and checked my own Postgres installations in Gentoo and openSuSE. Auto vacuum exists, and is enabled by default.

Re:why?

[Anonymous Coward]

Fortunately, you're not at risk of learning something.

Re:why?

[shentino]

PostGres competing with MySQL is like alpha competing with Intel.

Even though IMO PG is technically superior in every way, MySQL is more widely supported, both directly and indirectly as a backend for many systems.

In fact, I am building a personal website and I want to add a message board. Guess which database backend every single one of them supports?

And until everyone else above me in the supply chain overcomes their collective inertia, my hands are tied because as of yet I do not have sufficient temporal resources (i.e. spare time) to implement a board myself.

Re:why?

[asdf7890]

For instance if you never delete from a table there's no need to bother trying to vacuum it.

Not quite. Because of the way postgres operates (MVCC) UPDATEs will result in space appearing in table structures too. With an MVCC based DB nothing is updated in-place (actually, in any good DB nothing is updated in-place, but with MVCC this is more obviously implied by any good description of how things work with multiple distinct transactions present). When a row is updated new version is added and the old version is removed when the transaction is complete and no other transactions might refer to the old copy. This has significant advantages for some use cases and loads, and some disadvantages in other

The wikipedia page (http://en.wikipedia.org/wiki/Multiversion_concurrency_control) isn't a great description though there is a bit more relevant information in http://en.wikipedia.org/wiki/Snapshot_isolation.

I've not used postgres much in anger, so I'm no expert, but personally I thought that being able to manually schedule cleanup was a good idea performance wise.

Re:why?

[KingMotley]

Either you have a very limited imagination, or you are exaggerating because you are biased. In either case, you have rendered your opinion useless.

Re:why?

[DiegoBravo]

> I asked in what scenario it would be a superior option (to the well-informed application architect, of course).

Of course because MySQL's root password comes empty so the Agile developers avoid losing their costly time waiting for the local database nerd configuring the permissions and bothering the team with more passwords to remember....

Re:why?

[Anonymous Coward]

Does it scale better? Actually it does, at least the 5.4 branch, when compared to postgres 8.3 branch (http://dimitrik.free.fr/db_STRESS_MySQL_540_and_others_Apr2009.html).

Does it have better security? Not really.

Is it easier to manage in some way? That depends on the usage scenario. Several tools developed outside mysql make the usual cases actually easy to manage.

Is there a killer feature its two closest competitors lack? Yep, plugable storage engines, documentation, mysql cluster.

Roundup:
Until recently, mysql didnt scale so well as postgres. That changed and imho wont change back for a while. Mysql's pluggable storage engines allow to fit the server towards many more use scenarios then postgres can ever dream of - there is no one size fits all solution. Cons to mysql are that its quirky, has long standing bugs and to most people the project's politics are a complete mess. Postgres definitely wins when it comes to features, its more customizable security model and in some cases its manageability and license. Nice things about postgres are serverside languages and point in time recovery. Postgres can easily get CPU bound, doesnt understand query caching.

Mysql was, is and will be the default database for most web-related stuff - postgres fanboys should get over it. Mysql has the sister project Drizzle which now servers mysql as a testbed for different approaches to solving problems. Mysql started to focus on solving longstanding bugs, improve performance and is in the painful process of opening up and involving community.

So, both databases have their usage scenario. Neither one will disappear. Ever. But my bet goes with mysql/drizzle in the long run (meaning that mysql will equal postgres plus stuff not in postgres).

Re:why?

[Cow Jones]

I asked in what scenario it would be a superior option

I'm with you on that - in the last 7 years, I've used PostgreSQL exclusively for projects that were under my control. I'm subscribed on the mailing lists, I know about all the misconceptions regarding performance, and I know that MySQL is nowhere near as reliable and professional as PG.

But since you asked: I'm still running MySQL on most of the servers, and the reason for that (the only reason) is third party support. When you're installing a web-based CMS, or bulletin board, or bug tracker, or gallery, or whatever, chances are it will work better with MySQL. The people who write these things are often more familiar with MySQL, and Postgres support (if available) is sketchy at best. Try Drupal with PG, for example. The core modules work fine, sure, but as soon as you start installing some of the more exotic modules you'll run into trouble.

I've given up trying to force these applications to play nice with Postgres. They can use MySQL if they have to, and I'll stick to a real database for data that matters.

CJ

Re:why?

[vadim_t]

Oops. You're right there.

Re:why?

[Anonymous Coward]

What's the most negative number MySQL can store?

Is there such a thing as "the most negative" number? "-3 is more negative than -2" sounds weird.

Re:why?

[Lord Ender]

OK, so MySQL is more easily configured than Postgres? I must say the DBs I've set up have done fine with default configurations, both Postgres and MySQL. But I'll take your word for it that configuration is easier for your apps, which I assume are higher load than the defaults of either will handle gracefully. That sounds like a legit reason.

Re:why?

[Lord Ender]

There's no information in your post. Please try your troll again.

Re:why?

[A. Bosch]

Not sure why this was modded "Troll" nor am I understanding why GP is "Informative". I have to agree; there's a lot of MySQL bashing by Postgres wonks. Move on.

Re:why?

[KingMotley]

My post was not a troll, but making unprovable statements that don't include any facts that start with "I can't imagine" typically are. On the off chance I mistook your statement as a blatent troll, perhaps you could elaborate on what you meant by "I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter)". What was your reasoning for saying it? What idea were you trying to convey to us?

Did you mean to show us that you have a very limited imagination that couldn't possibly include any situation that you would EVER use MySQL, but perhaps other people with more imagination might be able to? Or were you trying to say that your imagination is large that you've thought about every conceivable situation that has happened, is currently happening, or will ever happen and in every case SQLite or Postgres is better, and we should take your word for it?

Re:why?

[Lord Ender]

You've outsmarted me! Yes you figured out that I am trying to tell you I have a "very limited imagination."

Or you could read sibling posts. Or you could keep on trollin. You're at strike 2 for having content.

Re:why?

[Splab]

People like you are undermining the industry. You straddle around claiming to be a database developer with x years under the belt, but you are in fact putting your clients data in grave danger and when shit finally hits the fan on your mysql installation you are going to wish you listened to the people who knew better.

Re:why?

[Splab]

Database 101 - the most important part of a database is to keep your data integrity, including telling you to go put your query where the sun don't shine if your data doesn't fit the schema.

Telling the program that the query you just submitted is fine and dandy and then changing the data is - if not the biggest nono in a database - a top 10 thing you just don't do.

Re:why?

[daveime]

perl -MCPAN -e 'install Bundle::DBD::mysql'

There, that wasn't hard, was it ?

Re:why?

[daveime]

I'm not so sure that MySQL has an auto-vacuum as such. Deleted rows etc will eventually slow down the indexes as they get fragmented, and the space AFAIK is not reused.

We run ANALYZE TABLES and OPTIMIZE TABLES once a month, and the performance boost right after these operations is very noticeable.

Re:why?

[Anonymous Coward]

A phrase like 'biggest negative number' would be ambiguous.

Re:why?

[Anonymous Coward]

Perhaps this is due in part to the fact that each member of the MySQL documentation team is a full-time professional with many years of DBA/coding *and* writing experience under his belt. One of their criteria is that you have to have published at least 4 or 5 books in the field just to be considered for a job.

Re:why?

[shutdown -p now]

WHY use MySQL? Gee, because it's well documented

Have you seen PostgreSQL documentation?

I actually use it as a general-purpose SQL reference quite often, when not working with PgSQL - it's really that good.

Re:why?

[Crayon Kid]

Many of us MySQL users see your Postgres question the same way: why use Postgres?

Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.

Take a look at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?

I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.

Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."

Now compare with the Postgres manual page describing their ACID implementation. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.

Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?

MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.

Re:why?

[richlv]

plus all the postgres zealots that come over to any mysql related article and praise pgsql make me vomit on a printed pgsql logo. ok, not really, but could you (the aforementioned zealots) please try to understand that your offense in mysql articles just makes people reluctant to even try pgsql.
if you feel such a huge need to pitch two opensource databases, go to pgsql threads and claim how bad mysql is there - then at least you don't pollute mysql related discussions with something i would classify offtopic at this point.
thanks.

Re:why?

[Azundris]

I can't imagine a scenario when I would chose to use MySQL

In all fairness, I'd be tempted to blame that on your imagination rather than the product. :)

Re:why?

[digitalchinky]

For a price there is always someone who knows better. Evidently you know better, but who are you? Where are you? How much do you charge? Where were you to inform us that our choices were wrong before we made them?

The vast majority of us are not sitting back in our leather recliner supplied by our fortune 500 overlord reflecting on how to shave a few CPU cycles off a query, we don't have a team of DBA's we can turn to during the planning and implementation stages. At best we have a handful of guys and girls churning out code to a deadline, though more commonly it's just some person nobody knows with a PHP book in hand scratching an itch, management notice and suddenly the title changes from Sector 7-G data entry drone to the resident CTO of a corporation with all of 30 people on the pay roll.

People make mistakes, hell, people barely know how to articulate what it is they want at the best of times, mostly they have no clue what is even possible - you mix this in with the sleaze selling snake oil in every facet of life, a little bit of internet drama, and you have this aforementioned shit splattering on the fan blades.

Instead of being unhappy that the industry is getting undermined by people who shouldn't be allowed in front of a keyboard, change your career goals, be the saviour, make a shit tin of money off the backs of these retards. Build a slick looking website with pictures of old wise men in glasses playing with their grand kids on the front lawn, sell your little patch of "I can do this better than anyone else"

Me, I just want a new motorbike, I'll churn out the code as best I can until that happens, every day I try to learn new ways of doing the same old stuff better, but once in a while I'll still log in to a production environment and chmod -R 700 / for kicks, then delete the audit logs. Screwing up is what we humans do in the real world.

Re:why?

[Daniel_Staal]

Heh. Yes, that was hard: The machine in question doesn't have access to CPAN.

And even then, the above just tries to download and compile the DBD. Which fails on many RedHat installs: You need to swizzle the build flags. Which gives it a chance of working, unless your build flags for Perl were wrong. Or the ones for MySQL. Or both.

Re:why?

[Anonymous Coward]

Just in case someone doesn't know - there's no need to bother with scheduling any vacuum runs since quite some time. It's taken care of by autovacuum. It's fast, too, and won't disturb ongoing database traffic in any meaningful measurable way.

I run real-time stock feeds using PostgreSQL, with parallel write and read workloads of many hundreds of transactions per second continuously, day in and out (both read and write, the majority are writes due to the nature of the data) with many clients executing queries in parallel. Auto-vacuums are scheduled by the database server as needed and typically run and complete without even a blip on the load or response times for the users.

No manual vacuum, analyze or mucking around in cron needed.

Administration is trivial. Performance stellar. Stability excellent.

PostgreSQL is great. Other databases might be too. Just giving my input.

Re:why?

[Lord Ender]

I wouldn't think of trying to force an app designed for one DB to use another. When I write my own apps, I need to pick something, and I have no strong reason to use one not the other.

Re:why?

[Slashdot Parent]

Say you need clustering or replication. Then, you would need MySQL because Postgres does not have a serious solution for you.

Slony-I is a dreadful hack that misuses triggers. It's easy to break, difficult to administer, and doesn't scale past a few nodes.

There is no postgres clustering solution that can add a node to the cluster without blocking all reads and writes as the added node syncs up. Sorry, that is not a real solution.

Postgres has definitely realized their error in forcing replication and clustering into third party apps, and they're going to include replication "real soon now" (although it's already slipped versions at least once).

But, sorry. You can't really use Postgres is a high-availability architecture because of the lack of decent replication and cluster support.

Re:why?

[Slashdot Parent]

Does it scale better? Does it have better security? Is it easier to manage in some way?

Yes.

PostgreSQL has no serious replication or clustering solution. MySQL does.

If you need high availability, then you need something other than Postgres.

Re:why?

[Slashdot Parent]

I imagine the intent is for database administrators to issue that command during scheduled maintenance windows. I agree that an "auto vacuum" feature would be preferable for many people. Is "auto vacuum" the major advantage of MySQL over Postgres, then?

Before auto-vacuum, I'd say it was a big advantage. Anything that can cause you to lose all of your data is a big deal, and it used to be that if you didn't vacuum your postgres tables, you'd lose all of your data eventually. MySQL has no such vacuum requirement.

Nowadays, with auto-vacuum, I'd say that's no longer an advantage. And all of the distros that I've worked with have auto-vacuum enabled by default.

Re:why?

[Eponymous Coward]

I think you are being a little harsh.

Our app is one that has a pre-populated read-only database (that is, we never do updates, only selects). The database has only a single client and has to deal with bursts of activity that peak at 10's of queries per second. The load we put on the database is orders of magnitude away from what MySQL can handle. This what I meant when I said it works well enough. In fact, SQLite would probably even be a better choice.

I have never claimed to be a database developer. In fact, people like me rarely do. People like me pick the right tool for the job (I hate that phrase) and don't spend all day fucking around gilding lillies. If the database was a critical component for my application, I would definitely spend more time and money on it.

Re:why?

[Anonymous Coward]

Well said.

As far as I'm concerned, there are only three databases:

Oracle 10G or later if you can afford it and have a capable DBA or three;

Postgres if you can't afford Oracle, because it's almost as good (Oracle has nicer management tools, though);

JavaDB for small embedded databases bundled with applications. I love JavaDB; it supports transactions (which I needed for an app), it's small and easy to work with, and it doesn't slow down the app its embedded into.

Anything else and you're wasting your time. BTW, I've been an Oracle DBA for the past several years, although I also wear a "Java Developer" hat.

P.S. If you ever want to make your boss' head explode, wait until he's nearby and tell HIS boss (who's in on the joke) the following:

"Yeah, I don't see why we're paying 40K per processor for our database... Can't we switch to SQL Server and train our developers on .Net? I bet we could port the entire database in a week or so."

My poor boss almost had an aneyurism. It was HILARIOUS.

Re:why?

[Anonymous Coward]

I can't imagine a scenario when I would chose to use MySQL

How about keeping track of how many times I fucked your mother up the ass?

Re:why?

[Anonymous Coward]

Maybe you should stop using shitty PHP software, developed by idiots who only know MySQL.

Re:why?

[Anonymous Coward]

Managing, developing and working with both MySQL and Postgres, I can say definitively that MySQL has many features that are far superior to Postgres.

Scalability is very high in the consideration with MySQL with the ability that will scale quite well, where as Postgres... well, meh. Chose the second hand scaling app.

For some reason the same process that we use to read, write and delete data leaves back data that needs a "vacuum" for some odd reason.

Where Postgres does shine, is with PostGIS. That is what pulls Postgres far ahead, but that is a minor pittance in our business.

We are dealing with millions of records consistently, but we by no means need to spend Oracle prices.

Re:why?

[Zarluk]

Someone mod the parent up, please ;-)

Re:why?

[jpkunst]

Exactly. The Postgres trolls are about as interesting as "BSD is dead", etc. Unfortunately they are invariably moderated "insightful". It's getting really tiresome.

Re:why?

[Anonymous Coward]

It's not so funny if the boss is an ignorant git who will pretend to go along while understanding nothing. The joke is quite lost on such a person and the fun is nil.

Heh

[Anonymous Coward]

An Open Database Alliance where the only database allowed is MySQL? Kinda reminds me of the World Series, where the only teams are from the USA.

Re:Heh

[emarks]

That's true. Those Canadian teams (now team) suck hard!

What is his motive?

[Anonymous Coward]

Though he contributed a lot to MySQL, he is the one who benefited most from MySQL when it was sold to Sun. So, we as a community contributed to MySQL, he took all the contributions, packaged it nicely and sold to Sun for 1 billion USD. Now that his contract with Sun is over, he is there again asking community to contribute more but not for the original MySQL because he does't own it. He wants all of you to contribute for a clone that he is going to own so that he can make more money in future.

Re:What is his motive?

[WankersRevenge]

You're free to do the same. What's the issue?

Who?

[fm6]

HEADLINE: MySQL Creates Open Database Alliance, Plans Refactoring

MySQL the database application? It created a new alliance? It plans to refactor itself? Astonishing, if true.

MySQL the software company? Uh, not, because Monty no longer has any connection with them.

You mean Monty did these things. Not "MySQL". His identification with MySQL is pretty strong, but I don't think they'll merge any time soon!

ATHF?

[Anonymous Coward]

Drizzle...

from the database-SHAKEup dept.?

Aqua Teen Hunger Force!

I'm confused

[Stone316]

I'll admit, I haven't followed MySQL that much but i'm confused as to the state its in now. With the original founders going off and doing related stuff it seems pretty fragmented.

Can someone piece it all together?

Re:I'm confused

[Anonymous Coward]

Let me sum this up for you then...

The future of MySql as we know it is serious jeopardy due to a couple companies and a few programmers.

Sun buys MySql project and hires the lead developer, programmer disagrees with company's direction and leaves, company gets bought out by another bigger shittier company named Oracle, who hasn't understood what a db or software dev was in over 20 (hince the 10 year old crappy 32x32 of a turtle).

Programmer leaves but still wants to control his project but unfortunately lost all rights to work on it without going through shitty company.

Put it this way, I won't be installing any newer builds from either party, particularly during major refactoring.

Re:I'm confused

[Splab]

No one can, you got several companies having their greased fingers involved, you got several different licensing systems for the same code base and the original developers all split into new forked projects.

MySql - TheirSql

[hey]

suggested name change.

MySQL AB ver. 2?

[Stan Vassilev]

It was during MySQL AB's time that MySQL began a stange play with the community by first dropping official community binary builds, and then severely delaying source code releases as well (while supplying commercial clients with more stable and up to date releases).

It was again during MySQL AB's time when the announcement came that MySQL's source code base will start to "close down", by releasing many new features only commercially, and with no open source code. When Sun bought MySQL AB, they reversed those policies and stood behind MySQL being open, without exceptions.

Now Mr. Monty Widenius has taken the money Sun paid for MySQL AB, and used it to open a new company and an "Open" alliance which is "designed to become the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other".

If even Mr. Widenius has noble intentions regarding MySQL, his past in MySQL AB and his current interaction with Sun/Oracle seem to leave another impression.

Re:MySQL AB ver. 2?

[Anonymous Coward]

I'm glad I'm not the only person that feels like this guy is running a huge scam.

Re:MySQL AB ver. 2?

[Anonymous Coward]

It was during MySQL AB's time that MySQL began a stange play with the community by first dropping official community binary builds, and then severely delaying source code releases as well (while supplying commercial clients with more stable and up to date releases).

It was again during MySQL AB's time when the announcement came that MySQL's source code base will start to "close down", by releasing many new features only commercially, and with no open source code. When Sun bought MySQL AB, they reversed those policies and stood behind MySQL being open, without exceptions.

Now Mr. Monty Widenius has taken the money Sun paid for MySQL AB, and used it to open a new company and an "Open" alliance which is "designed to become the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other".

If even Mr. Widenius has noble intentions regarding MySQL, his past in MySQL AB and his current interaction with Sun/Oracle seem to leave another impression.

It was during MySQL AB's time that MySQL began a stange play with the community by first dropping official community binary builds, and then severely delaying source code releases as well (while supplying commercial clients with more stable and up to date releases).

It was again during MySQL AB's time when the announcement came that MySQL's source code base will start to "close down", by releasing many new features only commercially, and with no open source code. When Sun bought MySQL AB, they reversed those policies and stood behind MySQL being open, without exceptions.

Now Mr. Monty Widenius has taken the money Sun paid for MySQL AB, and used it to open a new company and an "Open" alliance which is "designed to become the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other".

If even Mr. Widenius has noble intentions regarding MySQL, his past in MySQL AB and his current interaction with Sun/Oracle seem to leave another impression.

> It was again during MySQL AB's time when the announcement came that MySQL's source code base will start to "close down", by releasing many new features only commercially

Could you name one single feature which was released only commercially?

I've followed MySQL development pretty closely, and haven't heard of one commercial-only feature of the server.

Re:MySQL AB ver. 2?

[Anonymous Coward]

Google "mysql closing source"

Re:MySQL AB ver. 2?

[Hurricane78]

Why put up with all the hassle? Just use PostgreSQL, and be good. :)
Yes, you can do replication (the master/slave thing, aka S/M ^^) with it.

Re:MySQL AB ver. 2?

[Zarluk]

Yes, you can do replication (the master/slave thing, aka S/M ^^) with it.

Unfortunately, it's not that easy... as far as I know it doesn't support replication of tables that contains sequences :-(

Besides that, yes, PostgreSQL rocks :D

facebook uses it

[Toreo asesino]

...I saw in one presentation their chief architect did. They had no complaints about it; apparently it scales brilliantly as long as the db schema is very simple.

For heavy-weight databases though, I gather it's not so good.

Sure can

[/dev/trash]

visit http://www.postgresql.org/

what did Sun buy? lessons in OSS acquisitions

[cowdung]

A lesson in Open Source acquisitions:

1. Monty starts db called MySQL, trademarks and has copyright
2. Monty sells trademarks and copyrights to Sun (presumably for a ton of cash)
3. Monty leaves Sun
4. Monty forks MySQL calls it MariaDB

So in the end.

Sun has:
1. A trademark
2. Rights to the code
3. Right to sell MySQl under any license

Monty has:
1. GPL'd code he does not own
2. Credibility as the guy who knows about this
3. The ability to continue selling support services

So in OSS when you buy a product you don't really get too much do you? (At least if you can't hang onto the developers)

Re:what did Sun buy? lessons in OSS acquisitions

[zuperduperman]

> So in OSS when you buy a product you don't really get too much do you?

I think they got a lot from it: Monty is completely hamstrung because he doesn't own a line of the code in his new "Open" database. Unless he rewrites from scratch he is stuck with GPL even if he wants to give his code to his own wife. And that also means that no serious commercial company can use it because even the drivers are GPL (*not* LGPL) which means as soon as you touch it even to open a connection your own product turns to GPL (unless you buy a license from Oracle).

IMHO, the first thing that needs to happen (and which should have happened years ago) is that the MySQL GPL drivers need to be clean-room rewritten so at least you can link non-GPL code with it. Until then I've got no interest in it and it loses to PostgreSQL before I even get to thinking about a technical comparison (and please note: I've got nothing against GPL in general, I just don't want it forced inside my own processes by my database).

Re:what did Sun buy? lessons in OSS acquisitions

[Anonymous Coward]

Monty is completely hamstrung because he doesn't own a line of the code in his new "Open" database. Unless he rewrites from scratch he is stuck with GPL even if he wants to give his code to his own wife. And that also means that no serious commercial company can use it because even the drivers are GPL (*not* LGPL) which means as soon as you touch it even to open a connection your own product turns to GPL...

We're talking about changing that, but I'm rather glad we waited until after Monty left, as it's rather entertaining to see him on the receiving end of the very same problem he insisted on creating in the first place.

Monty Widenius

[StikyPad]

*Opens the envelope*

What do you call a game show host in a goatse pose?

Re:Monty Widenius

[Anonymous Coward]

Mod me whatever but I swear every time I read it as Monty Wide-anus and a weird caricature comes into my head.

!alliance

[Samah]

This is hardly an "alliance" if it's centred around MySQL. If the ODA had been formed from teams from many of the popular DBMS's, then yes I would call it an alliance.

Someone has to do it

[Thalaric]

I would question this guy's motives trying to take back MySQL after selling it to Sun, if it wasn't for the fact that Sun and now Oracle have done such a poor job with it. Whether or not you hate MySQL, if it's going to improve it needs someone to move the project forward.

Does anyone really see Oracle doing that?

Re:Someone has to do it

[rackserverdeals]

fact that Sun and now Oracle have done such a poor job with it.

If it's a fact can you point to some evidence of what Sun and Oracle (which doesn't yet own and control Sun/MySQL) have done that can be classified as a poor job that wasn't happening before Sun bought it?

When Sun bought it, the old MySQL AB execs were talking about keeping some new stuff closed but Sun made them open source it.

Some of the latest releases probably came out too early (according to Monty) but that's not any different than when MySQL AB was it's own entity.

Since Sun bought MySQL they kept it more open and increased it's revenue.

Re:Someone has to do it

[Thalaric]

Since Sun has had mysql they've had a disasterous release, a mass exodus of their mysql developers, and at least three forks. If that is great management and strong leadership then I stand corrected.

I didn't think I needed to expand on Oracle since everyone is speculating about whether mysql even has a future.

Re:Someone has to do it

[Anonymous Coward]

Since Sun has had mysql they've had a disasterous release...

According to Monty, perhaps. Everybody else seems to like it pretty well, however.

...a mass exodus of their mysql developers...

It's too bad some of those folks left, but basically they couldn't handle change, and -- not to sound crass -- but we do have quite a few more very good developers who actually do their jobs and don't waste cycles playing politics.

...and at least three forks.

And couple more of our own. :)

Welcome to GPL. Feel free to celebrate your arrival by starting a fork for yourself, if you like. Won't bother us, and we look forward to using your patches just like we use patches from Google, Novell, and Percona if and when it suits us.

If that is great management and strong leadership then I stand corrected.

Well, you'll just have to excuse me if I don't consider the lack of clear direction and all self-contradictions we were saddled with when Monty was running the show don't exactly *my* definition of "great management and strong leadership".

I didn't think I needed to expand on Oracle since everyone is speculating about whether mysql even has a future.

Only for values of 'everyone' approaching 'people who are likely to obsess on questions such as "OMG, am I going to get hit by a bus when I go to lunch today?"'.

Re:Someone has to do it

[rackserverdeals]

Since Sun has had mysql they've had a disasterous release, a mass exodus of their mysql developers, and at least three forks. If that is great management and strong leadership then I stand corrected.

Have you ever read Monty's blog?

MySQL AB was the reason that the release wasn't up to Monty's standards and they had done that in the past before Sun bought them. It wasn't Sun that made it that way.

One would have thought that MySQL AB (now the MySQL department at Sun) should have learned something from our too early release of MySQL 5.0 but unfortunately this is not the case.

So yeah, technically they are Sun employees now, but it was the former MySQL AB guys doing the same thing they did before that caused the release to be the way it was.

The problems Monty seems to have exist before Sun bought them. I remember rumors and news stories about spats with Mickos all th time. Monty created MySQL, then got VC money and didn't have the same amount of control he had. When Sun bought them, he was hoping things would change but they didn't.

Seems like if Monty wanted to be happy, he never should have received outside financing and accepted people he couldn't fire to the companies executive team. Unfortunately, you can be extremely rich or you can be extremely happy, you can't always be both.

What mass exodus? I've only read of maybe 3 people leaving.

I didn't think I needed to expand on Oracle since everyone is speculating about whether mysql even has a future.

Yes you do. Just because people are speculating about something doesn't make it reasonable. Oracle already owns InnoDB which is an important part of MySQL and hasn't used it to screw over MySQL. They also own Berkley DB and have said they will not kill MySQL.

Monty is doing one thing, Sun the other

[Anonymous Coward]

Two different stories:

1. Monty announces Open Database Alliance
2. Sun's Manyi Lu announces the Sun server refactoring project.

Bad name

[Anonymous Coward]

Its not Open Database Alliance. If it was other Open Source Databases would be there.

Open MySQL Alliance - yea.

Anonymous Coward

[Anonymous Coward]

It's about choice.

Comment removed

[account_deleted]

Comment removed based on user account deletion