Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Databases Programming Software Sun Microsystems IT

Locating the Real MySQL 335

An anonymous reader writes "In a blog post, Patrick Galbraith, an ex-core engineer on the MySQL Server team, raises the question: "What is the official branch of MySQL?" With Monty Widenius having left Sun and forked off MySQL for MariaDB, and Brian Aker running the Drizzle fork inside of Sun, where is the official MySQL tree? Sun may own the trademark, but it looks like there is doubt as to whether they are still the maintainers of the actual codebase after their $1B acquisition of the code a year ago. Smugmug's Don MacAskhill, who is the keynote at the upcoming MySQL Conference, has commented that he is now using the Percona version of MySQL, and is no longer relying on Sun's."
This discussion has been archived. No new comments can be posted.

Locating the Real MySQL

Comments Filter:
  • PostgreSQL (Score:5, Informative)

    by mlwmohawk ( 801821 ) on Monday March 30, 2009 @08:00PM (#27395883) []

    Just saying.

  • by Matchstick ( 94940 ) on Monday March 30, 2009 @08:00PM (#27395885)

    The MariaDB link should be []

  • Re:PostgreSQL (Score:1, Informative)

    by digitalunity ( 19107 ) <{moc.oohay} {ta} {ytinulatigid}> on Monday March 30, 2009 @08:04PM (#27395933) Homepage

    I agree. Use it, live it, love it.

  • Allow to say: (Score:5, Informative)

    by drolli ( 522659 ) on Monday March 30, 2009 @08:10PM (#27396003) Journal

    While i am *not sure* of the details, i am pretty sure that SUNs lawyers did not forget to make very definite regulations for maintainers leaving, forking of etc. As far as i undrstood, sun bought the code *and* the rights. As many people dont understand GPLed code still has an owner. Independent of that mysql may still be a trademark.

    So the standard (GPL) way is to rename the project and add the staement that you modified it which *somehow* makes it different from the "official" branch (to define that, that is the branch which does not carry the notice that it was modified and which is published under the prior, maybe (tm)ed, name).

  • Enough already! (Score:5, Informative)

    by Wee ( 17189 ) on Monday March 30, 2009 @08:11PM (#27396019)
    And now pretend that you are, like many thousands of other people, hosted in a place that doesn't offer it. Or run software which can't talk to it. Or have staff who aren't trained in its use or upkeep. Or... a hundred other things.

    Enough with the knee-jerk elitism. MySQL is just fine for quite a lot of tasks, and the article isn't about the religious battle between DB packages.

  • by Ungrounded Lightning ( 62228 ) on Monday March 30, 2009 @08:14PM (#27396055) Journal

    This calls into question whether it's viable to sell a business based on open-source software.

    I was under the impression that MySQL operated with a full-featured, proprietary, licensed, commercial version getting immediate upgrades and support, plus a less-featured open source version with releases of code (ported?) from the full-featured branch that ran some months behind the for-pay version.

    If that's right, I'd say Sun bought the whole shebang, including the code and customer bases for the licensed deluxe version, not just the open-source codebase, trademark, and employment contracts of a room full of engineers.

    As for the viability of "sell[ing] a business based on open-source software", why don't you bring that up with the stockholders of Red Hat? B-)

  • Re:Enough already! (Score:5, Informative)

    by digitalunity ( 19107 ) <{moc.oohay} {ta} {ytinulatigid}> on Monday March 30, 2009 @08:20PM (#27396111) Homepage

    It's not a religious battle, it's about using the best tool for the job. MySQL may be very easy to setup, but just fyi, PostgreSQL is a snap to set up now on Windows or Linux.

    Looking for reasons to use PostgreSQL?
    Much better index support.
    Kerberos or LDAP access controls.
    Better native Unicode support.

    If you're hog-tied to MySQL because of your software, well so be it. But if you have a choice, the winner should be fairly obvious.

  • by ximenes ( 10 ) on Monday March 30, 2009 @08:45PM (#27396331)

    For the database server itself, there is no difference between MySQL Community Edition and MySQL Enterprise Edition besides the release schedule. The community edition (aka the regular one everyone uses) has been pared down to 4 releases a year, which are cherry picked from the enterprise releases.

    However, the source is completely available for the enterprise releases, and you are able to compile and install them yourself. This is what Percona is doing, for instance (plus some other patches).

    With that said, MySQL has other software that comes along with the enterprise edition that is not open sourced to my knowledge. A query analyzer, monitoring, and other goodies. Personally I prefer to find their equivalents in the open source world, but I'm sure some people buy and use these packages.

  • Re:PostgreSQL (Score:3, Informative)

    by VGPowerlord ( 621254 ) on Monday March 30, 2009 @09:01PM (#27396481)

    Hey, maybe people have a reason to use MySQL - a product that only supports that db, or developers who aren't particularly familiar with what relational databases are supposed to be like.

    I don't know why this is marked as Funny... there are far too many programs or even webapps (PHP ones in particular) that only work with MySQL.

  • Re:PostgreSQL (Score:1, Informative)

    by Anonymous Coward on Monday March 30, 2009 @09:07PM (#27396547)

    Yes, it is. Yes, it does.
    More here:

  • Re:PostgreSQL (Score:5, Informative)

    by carlzum ( 832868 ) on Monday March 30, 2009 @10:03PM (#27396973)
    The latest version of each have brought the two much closer in terms of performance and features. Historically, MySQL has been regarded as faster for simple querying and DML statements, but lacked full ACID compliance. PostgreSQL supported more advanced features like a PL/SQL style procedure language, transaction support, and data compression.

    Today, the big difference is PostgreSQL is considered better on higher-end hardware with concurrent I/O support and better multi-core support. MySQL is considered better on clusters of lower-end hardware. There is a Wiki comparing the two [] in much better detail.

    Personally, I work with both in large production systems and can fill a few pages on likes and gripes. I'm on MySQL 4.1, so concurrency is a concern, and PostgreSQL's replication is a pain. Unless you're trying to solve a problem MySQL can't satisfy, I wouldn't switch for the sake of change. Your time is probably better spent upgrading to MySQL 5.1.
  • Re:PostgreSQL (Score:5, Informative)

    by greg1104 ( 461138 ) <> on Monday March 30, 2009 @11:04PM (#27397365) Homepage

    The Oracle pl/SQL -> PostgreSQL pl/pgSQL link you suggested was from PostgreSQL 7.1, pretty ancient at this point. PostgreSQL 8.3 Porting from Oracle [] is a current resource.

  • Re:PostgreSQL (Score:5, Informative)

    by rackserverdeals ( 1503561 ) on Monday March 30, 2009 @11:24PM (#27397493) Homepage Journal

    Early on, PostgreSQL focused on complete implementation and correct behavior over speed, then worried about adding speed later. MySQL focused on speed, and worried over correctness and completeness later. Since then, PostgreSQL has sped up a lot, and MySQL has shaped up in implementation completeness. But it won't surprise me if PostgreSQL still has a few extra features.

    This comparison of PostgreSQL vs MySQL [] is on PostgreSQL's wiki but it seems very fair.

    The most interesting bit is this:

    It is worth observing that the database engine is part of the core of PostgreSQL, whereas InnoDB is a dual-licensed product presently licensed from Oracle Corporation. It is uncertain how Oracle may alter InnoDB in the future as they act in competition with MySQL AB, whereas PostgreSQL has no such conflict of interests. MySQL AB has been working on a new database engine core called Falcon in order to free themselves from this situation, but historically developing a database core engine that is both fast and reliable has required many years of work and testing before a mature product suitable for production use is available. Initial benchmarks suggest Falcon has plenty of rough edges that need to be addressed.

    The forking of MySQL is going to split resources and creating that replacement for InnoDB may take longer.

  • by digitalunity ( 19107 ) <{moc.oohay} {ta} {ytinulatigid}> on Monday March 30, 2009 @11:58PM (#27397695) Homepage

    For starters, the database schema is extremely complicated, much more so than is necessary for most companies. The web interface to eBusiness isn't too bad, although even on big iron it is still pretty slow for a lot of filter and search operations.

    The web-launched Java interface takes a LOT of resources per instance; it's very slow on a typical desktop computer. The java interface is MDI, whereas separate windows would be quite a lot easier for users to use. It's also single threaded, meaning one blocking MDI child window blocks the entire eBusiness instance. Clicking the List of Values[...] object is scriptable and in some situations isn't very intuitive. In some cases it will not check the associated field or entered text first, meaning it performs a wildcard search. If done in a field that is populated with hundreds of thousands of records, this can block your eBusiness for 10 or 20 minutes. There is no "break" either, you let it run or you kill it and lose whatever didn't have saved in other MDI children windows.

    This is just a short list. There are a lot of reasons Oracle eBusiness is a huge frustration for users and developers.

  • Re:PostgreSQL (Score:4, Informative)

    by wolfie123 ( 1331071 ) on Tuesday March 31, 2009 @01:22AM (#27398235)

    Why do you like [PostgreSQL] so much?

    The reason we use PostgreSQL instead of MySQL at work is mainly because the JDBC drivers for MySQL are GPL licensed, while Postgres' isn't.

  • Re:*Cough* (Score:2, Informative)

    by thzinc ( 679235 ) on Tuesday March 31, 2009 @01:37AM (#27398327) Homepage
    The real moral of the story is to use the proper collations where necessary. Migrating from a case-insensitive to a case-sensitive collation was the real problem. Also, indexing with the right collation is no problem.
  • Re:PostgreSQL (Score:3, Informative)

    by Mark Round ( 211258 ) on Tuesday March 31, 2009 @02:45AM (#27398673) Homepage

    Well, not natively. But there are a bunch of 3rd party replication/clustering products that do that for you. The original thought was that a replication engine should be pluggable as everyone has different requirements, so it shouldn't be in the main database. However, they've relaxed that stance a little - there was an announcement of an effort to build a native replication engine being in for 8.4, but it looks like it won't make it until 8.5 or so. But they are working on it (and they recognise something like MySQL's replication has attracted a lot of developers so I would imagine something along those lines).

  • Re:Enough already! (Score:5, Informative)

    by |DeN|niS ( 58325 ) on Tuesday March 31, 2009 @05:30AM (#27399531)

    i asked you a valid question, how does innodb not maintain referential integrity? you bring up myisam. i didn't mention myisam. i know myisam isn't ACID. i asked you how innodb isn't. and as for error reporting, []. so again, how does innodb not take referential integrity and error reporting seriously?

    Well, how about completely ignoring the "REFERENCES othertable(othercolumn)" syntax for foreign key constraints without as much as a warning in even the strictest mode, leaving you without referential integrity without any way of knowing?

    Or from the manual: "By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes there is a chance that the last statements of the binary log are lost. To prevent this, you can make the binary log be synchronized to disk after every Nth binary log write, with the sync_binlog global variable (1 being the safest value, but also the slowest)."

    So InnoDB still defaults to non-ACID behaviour, but it doesn't stop there yet:

    More from the manual: Even with [sync_binlog] set to 1, there is still the chance of an inconsistency between the tables content and the binary log content in case of crash. [...] This problem can be solved with the --innodb-safe-binlog option (available starting from MySQL 4.1.3), which adds consistency between the content of InnoDB tables and the binary log. For this option to really bring safety to you, the MySQL server should also be configured to synchronize to disk, at every transaction, the binary log (sync_binlog=1) and (which is true by default) the InnoDB logs.

    Another option if you want ACID. Oh wait, there's a 3rd, since binlog defaults to off so you need to enable that too. Three options have to be changed from their defaults to get durability after each and every single commit (when we're talking databases, that's kind of what I expect. If you don't, that's fine, but we're not talking about the same thing then)

    , are you referring to companies like google, yahoo, or alcatel-lucent? need i really go on?

    Stick to apples-apples comparisons. None of those companies are using MySQL as a relational database (say, doing their accounting in it or trusting their business on it), sure Google uses it as a memory-only non-transactional clustered datastore with an SQL query interface, after having put in a lot of patches to make that work, but so what? Yes, use it for that, sure use MyISAM for your blog, but when we're talking about a proper relational database where "commit" means the data is stored, where a foreign key means a foreign key and where you would run your core business on it then stick to those cases where it's actually used as such. A better example for that is Skype, which runs its entire operations from buddylists to billing on Postgresql.

  • Re:PostgreSQL (Score:3, Informative)

    by mlwmohawk ( 801821 ) on Tuesday March 31, 2009 @05:50AM (#27399601)

    Why do you like it so much? Is it faster with large datasets? Does it support backups/replication/some other great to have feature?


    Here's one: On a large table, on a live site, create or drop an index. MySQL locks up until its finished, PostgreSQL keeps working.

  • Re:PostgreSQL (Score:4, Informative)

    by Dragonslicer ( 991472 ) on Tuesday March 31, 2009 @08:59AM (#27400657)
    To expand on that a bit, MySQL as a whole is GPL, while PostgreSQL is BSD licensed.
  • Re:Enough already! (Score:3, Informative)

    by Dragonslicer ( 991472 ) on Tuesday March 31, 2009 @09:10AM (#27400759)

    ...or if the application you're dealing with assumes or in some way depends on the case insensitive behavior of MySQL. That alone could make switching pretty rough.

    To be fair to MySQL, the case-insensitive behavior is following the SQL standard. Not to say that I like the idea, but it is in the standard.

  • Re:PostgreSQL (Score:2, Informative)

    by MinistryOfTruthiness ( 1396923 ) on Tuesday March 31, 2009 @09:29AM (#27400997) Homepage Journal

    Are you kidding? PG has incredible docs.

    Go to their site ( and click "Documentation." Heck, I'll do it for you: []

    Witness online documentation (with and without comments!) for the last FIVE server versions. Start poking around in that documentation and it doesn't take long to realize that documentation is far from "lacking."

  • Re:PostgreSQL (Score:3, Informative)

    by quantum bit ( 225091 ) on Tuesday March 31, 2009 @09:43AM (#27401151) Journal

    When was that? PostgreSQL has been using MVCC [] for as long as I can remember (as least since 6.0+, probably earlier), which is the same type of concurrency control used by Oracle. The implementation is a little different, but the effect is the same. Much more efficient than the locking method used by MySQL and MSSQL until fairly recently (SQL Server 2005 and InnoDB use MVCC).

  • Re:Enough already! (Score:3, Informative)

    by tepples ( 727027 ) <tepples@gmail.BOHRcom minus physicist> on Tuesday March 31, 2009 @10:41AM (#27401971) Homepage Journal

    When I write NOT NULL in a column, it doesn't necessarily mean I want to enforce that I MUST supply a value during any INSERT (and indeed then have to check that my INSERT actually worked and check for possible returned errors, coding exceptions etc). Therefore I always supply a DEFAULT value, that the DB can safely insert in that column, IF I haven't specified anything different during the INSERT.

    Create a table representing customers. I'd specify the column for the customer's name as NOT NULL, so that the database moans when I try to INSERT a row with a NULL name, in the same way that it would moan when I try to INSERT a row that duplicates a PRIMARY KEY. I'd probably even put in a trigger to moan when the app tries to set the column's value to an empty string or any other string without an alphanumeric character. What would you specify as the default value for the customer's name?

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.