Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Comparing MySQL and PostgreSQL 2

Posted by ScuttleMonkey on Mon Sep 05, 2005 02:05 PM
from the backend-makes-the-frontend-go dept.
Mr. Jax writes "6 years ago Mr Poet submitted the story Comparing MySQL and PostgreSQL. Since then both databases have evolved to wherever they are today. Are the points raised 6 years ago still valid? What has changed? Are there other things to consider since then (e.g. licensing)?" This is certainly a valid question since both databases have had to evolve with the times. Have these applications been specialized to fit a particular niche market or are they both still strong competitors? What does the horizon look like for the development of these programs, especially considering the recent MySQL partnership with SCO?
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Another question (Score:5, Insightful)

    by Eightyford (893696) on Monday September 05 2005, @02:10PM (#13484589) Homepage
    Sure it's slashdot and we all love free software, but how do these two compare with oracle, sql server and other non-free db's?
    • Re:Another question (Score:5, Interesting)

      by Jerry (6400) on Monday September 05 2005, @02:27PM (#13484686) Homepage
      PostgreSQL compares very well to Oracle.

      I use PostgreSQL as a test database against which I write and test QT applications. I can switch an app between the two backends by changing only a few lines of code and recompiling, or I can build the switching capability into the app. Using PostgreSQL reduces the number of access licenses required for Oracle, or doesn't waste existing connections.

      If I had my way I'd use PostgreSQL as the primary database, but some folks believe you've gotta pay money or the app isn't any good. As long as it's their money and not mine.
    • Re:Another question (Score:5, Informative)

      by ron_ivi (607351) <sdotno AT cheapcomplexdevices DOT com> on Monday September 05 2005, @02:40PM (#13484766)
      This page [arvin.dk] is the best document I've seen comparing each of the majordatabases (Oracle, Postgresql, DB2, MySQL, SQL Server) not directly against each other, but against the SQL Standard. In cases where at least one of the databases differs from the standard, this guy's article shows both the SQL called for by the standard, and how each of the implementations may either follow or deviate from the standard.
      • by Dogtanian (588974) on Monday September 05 2005, @02:28PM (#13484693) Homepage
        Oracle has the 'non benchmarking' clause that prevents you from doing that.

        Then arrange to have the benchmarking done in a country which won't uphold anti-competitive bullshit clauses (and when Oracle protest that the license lets them sue the guy in the jurisdiction of Buttfuck, Illinois, will tell them where they can stick their extradition request).

        Although I reckon such a case (brought by Oracle) might still get thrown out in a US court, I wouldn't bet my life savings on that, and the US legal system means you're unlikely to get fees paid if Oracle lose (does this *ever* happen in the US?); a great way for the large company to effectively win by attrition if the benchmarkers don't have that much money.
      • by Stinking Pig (45860) on Monday September 05 2005, @03:44PM (#13485157) Homepage
        SQL Server gets a lot of flack on /., I'd be interested to know why? I've worked a fair amount with it, Oracle 8 and 9, Postgres, and a little bit of MySQL. I've also done extensive benchmark testing of SQL/Oracle/Postgres handling the same load on the same hardware (shh, don't tell Oracle :).

        My experience leads me to beleive the following things:
        1) MS-SQL is a high quality database that is ridiculously easy to set up, tune, and maintain. It is also very expensive.
        2) Postgres is a high quality database that is ridiculously easy to set up and maintain, but fairly difficult to tune. However, its performance is just as good as SQL server as long as you stay away from nested loops(*). It is also fairly inexpensive (free license, but increased TCO).
        3) Oracle is a pig, and it requires a professional, certified swineherd. If you spend an amazing amount of money on licenses, gear, and certified DBAs you will presumably get good performance; I however was never able to get it past 60% of the performance of MS-SQL or Postgres.

        (*) Nested loops are like candy to SQL server, and I've heard this is the same for Sybase (understandably). Deep sets of nested loops will kick the other databases I've tested in the teeth. Given an instruction with several nested loops and 16 million rows of data, I got results from SQL server in 5 minutes, results from Oracle 9 in an hour, and results from Postgres in 18 hours. This was a year ago and Postgres has changed, so it might be better now. Does MySQL handle them well?
      • Re:MySQL vs. Oracle (Score:5, Informative)

        by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Monday September 05 2005, @03:26PM (#13485052) Homepage Journal
        MySQL supports all of the Oracle features you need to build and operate an enterprise software system.

        As of today, MySQL 4.1 [mysql.com] is the current release. 5.0, the current development snapshot, is the first to support stored procedures. Since the choice today is between a tested system and stored procedures, it most certainly does not "support all the Oracle procedures [I] need to build and operate an enterprice software system".

        Next year? Maybe. Right now? No way, according to mysql.com.

      • Re:MySQL vs. Oracle (Score:5, Informative)

        by oGMo (379) on Monday September 05 2005, @03:37PM (#13485114)
        MySQL supports all of the Oracle features you need to build and operate an enterprise software system.

        HAHA. Right. Tablespaces? Failover? High availability? Row-level locking? Stored procedures? Triggers? Multimaster replication? SQL conformity? I could go on, and on...

        MySQL's new administration tools are significantly better than Oracle's out of the box tools (This is why a year ago I refused to use MySQL for production, and now I've switched everything).

        MySQL is much easier to manage. I don't know anybody who runs a heavily loaded Oracle server in production without spending significant $$$ on DBAs and commercial tools. I feel quite comfortable doing this with MySQL.

        Yes, Oracle's builtin tools suck. However, others are available. This is basically "I'm not an Oracle DBA, but MySQL was easy for me, so it's better than Oracle!"

        MySQL performs pretty much the same as Oracle out of the box (and I think it is easier to tune).

        Yes, and anyone who's using a db tuned out of the box isn't doing significant work.

        [snip whining about blobs]

        Blah, blah, Oracle is hard. Get a DBA and a real developer. This is what they're paid for.

        I think that anybody deploying Oracle for non-Oracle applications is going to have to very seriously consider MySQL if for no other reason than all the DBA salaries you can get rid of.

        Oh, that's right, you want us to get rid of the people with a clue, because you have to pay them. Brilliant! So I guess we'll call you at 3am on Sunday morning when our servers crashed, we have to restore from rollback segments on our failover cluster... oh wait. MySQL can't do that.

        If you want to buld a $1M cluser, stick with Oracle (for now). If you want to run application specifically designed by (or for) Oracle, stick with Oracle. Otherwise, switch at the first opportunity.

        If you're building a big expensive app, you might look and see if PgSQL can support you. If you're building a crappy little webapp, you might check out PgSQL, because it's fun and you'll get some experience with a real database.

        Given PgSQL is free and not all that hard to manage, I can't think of a single reason for switching to MySQL.

      • Re:MySQL vs. Oracle (Score:5, Informative)

        by ttfkam (37064) * on Monday September 05 2005, @03:42PM (#13485143) Homepage Journal
        1. MySQL supports all of the Oracle features you need to build and operate an enterprise software system.
        Ummm... no. MySQL does not have user-defined data types, object-relational extensions, full support for the CHECK constraint (a big one IMHO), views in a stable release, updatable views, rules, stored procedures in a stable release, synonyms, support for more than one autoincrement column per table, automatic conversion of code pages between client and server, nested transactions, complete trigger support, access privilege grouping, access to multiple databases in one session, multi-master replication, gateways to other DBMSs, XML data and transformation tools, and better tools for recovery from failures.

        You can use MySQL for your enterprise apps, but it is not Oracle. MySQL, while boasting impressive database sizes, is not even close to competing with Oracle (or DB2 or Sybase) on the largest deployed database sizes.
        2. MySQL's new administration tools are significantly better than Oracle's out of the box tools (This is why a year ago I refused to use MySQL for production, and now I've switched everything).
        The enterprise is not as price-sensitive as the SOHO market. Very few that buy an enterprise Oracle license use the out-of-the-box tools.
        3. MySQL is much easier to manage. I don't know anybody who runs a heavily loaded Oracle server in production without spending significant $$$ on DBAs and commercial tools. I feel quite comfortable doing this with MySQL.
        See my answer to number 2.
        4. MySQL performs pretty much the same as Oracle out of the box (and I think it is easier to tune).
        Only in environments that MySQL can handle. Oracle can handle scenarios where MySQL cannot run at all let alone run fast.
        5. MySQL's supposed gotchas pale in to comparison to Oracle's. When I first used MySQL BLOBs it simply worked. I opened up the administration programs and I could actually see the images in the database. It was so beautiful I wanted to cry. I can't count the number of times I went through Oracle BLOB/CLOB hell with different platforms. (Not just getting them in there, but actually getting them to work with third party applications which is the real pain.)
        Agreed. Oracle definitely has its warts.

        That said, migration to and from Oracle is easier with PostgreSQL or Firebird -- especially if you start on the lower end. MySQL has been so far from SQL standard compliance, you may not know when you're doing something really weird. MySQL 5.0's strict mode has helped tremendously with this. Too bad it's not ready for production yet.
  • Also (Score:5, Funny)

    by TheRaven64 (641858) on Monday September 05 2005, @02:14PM (#13484608) Homepage Journal
    I have been wondering, which is better, vi or emacs?
  • Spatial databases (Score:5, Informative)

    by MostlyHarmless (75501) <artdent AT freeshell DOT org> on Monday September 05 2005, @02:23PM (#13484662)
    I don't have any thoughts about the more general question, but PostgreSQL is much better at storing spatial data than MySQL. MySQL has spatial functions built in, but it only supports a subset of the OpenGIS functions [mysql.com] (basically anything that can be done entirely with bounding boxes). PostgreSQL uses an external modulem PostGIS [refractions.net], which supports the full OpenGIS specification and a bunch of other extension functions besides. I've used MySQL by default simply because it is more familiar to me, but I've switched to PostgreSQL for my current project simply because of the spatial data module.
  • by caluml (551744) <slashdotNO@SPAMspamgoeshere.calum.org> on Monday September 05 2005, @02:23PM (#13484665) Homepage
    The DBAs I worked with always told me "Postgres is better". But I tried it a good few years ago, couldn't install it, it didn't "just work", and I was not that good with Linux at the time, so I just moved on to the next thing - MySQL.
    MySQL was good enough, and all the stuff that hardened DBAs said to me - "It doesn't do transactions", or "It handles NULLs wierdly", etc, just didn't apply.

    But when I tried to do a query like this: SELECT * FROM foo where bar NOT IN (SELECT blib from wheee) - MySQL advised me that it "didn't do" "NOT IN" queries. I tried to work around it, but after trying all the JOINs I could, it just didn't seem like something that I could get round. (I wasted quite a long time trying to work around this, and although I'm sure that some really top DBAs out there can do it, I couldn't.)

    So, mysqldump > mysql.dump, and then restore into Postgres. :%s/mysql_/pg_/g in all my PHP files. Change mysql_error to pg_last_error, and fiddle with pg_num_rows, and it all worked. Moreover, one huge query that took 25 seconds to complete in MySQL (lots of JOINS and nastiness) took about 1 second in Postgres.
    I've never looked back. MySQL is now just coming to fill in all the gaps it's missing - but just go with Postgres. It's rather good.
    No mention of SQL servers can go without the Gotchas: Mysql [sql-info.de] and Postgres [sql-info.de]. The worst MySQL is probably that it modifies data as you insert it without throwing an error. Yuk.
  • Heavy (Score:5, Informative)

    by HadenT (816717) on Monday September 05 2005, @02:41PM (#13484776)
    I'm using PostgreSQL and MySQL, from my experience:
    1. I've never encountered corrupted data with mysql (It seems to be urban legend), and I have worked on tables with billions rows for two years.
    2. PostgreSQL has more features and/or is more complete (simple example can be auto_increment vs. sequences)
    3. PostgreSQL is heavier, and I hate statistics collector subprocess via udp (which seems to be eating 1-2% cpu all the time)*
    4. mysql isn't much (if any) faster.

    * - it's unlikely but possible my configs are to blame.
  • by melted (227442) on Monday September 05 2005, @03:19PM (#13485013) Homepage
    One thing to consider - collations and Unicode support. Believe it or not, folks, Postgres does NOT support case-insensitive string comparisons. Or, more exactly it does, but you end up doing full table scan and converting everything into upper/lowercase, which is not an option on all but the smallest of the datasets. And even converting to upper/lowercase is a BIG problem for PostgreSQL, because it's UNICODE support is quite poor. So if your project has even remote possibility of using non-English textual data in lookups, steer clear of PostgreSQL.

    There's a discussion about including support for IBM ICU, but as of right now there's no proper collations/unicode support in PgSQL, aside from storing character data in UTF-8.

    MySQL is much better in this regard.
  • The scoreboard (Score:5, Informative)

    by ttfkam (37064) * on Monday September 05 2005, @03:20PM (#13485018) Homepage Journal
    http://www.huihoo.com/postgresql/mysql-vs-pgsql.ht ml [huihoo.com]

    Changes/corrections since that study was made:

    PostgreSQL now natively supports BLOBs directly in tables (bytea type) as opposed to using oid references.

    PostgreSQL has always had "better than row level" locking, Multi-Version Concurrency Control.

    PostgreSQL has added Java and Ruby to its list of stored procedure languages.

    ----------------

    Now, here's the caveat. MySQL 5.0 is still marked as a "development release (use this for previewing and testing new features)" so I didn't include it in the above. If we include MySQL 5.0, we must also include PostgreSQL 8.1, currently in beta.

    MySQL 5.0 adds views, stored procedures, triggers, cursors, the bit data type, up to 65K varchar fields, two new storage engines (federated and archive), and a strict mode.

    PostgreSQL 8.1 adds two-phase commits, a role system, shared row level locks using SELECT, and many speed improvements.

    The strict mode in MySQL is most exciting to me. I always bought the argument that MySQL could have fewer features in exchange for greater speed. But there is no excuse (in my opinon of course) to accept random strings into numeric fields and other such contrivances (MySQL gotchas [sql-info.de]). Data integrity in a database should not be an optional feature.
  • by adturner (6453) on Monday September 05 2005, @04:09PM (#13485275) Homepage
    Short story, mysql.com's interpretation of the GPL is frankly a lot more strict then mine or my reading of the FSF's FAQ on the GPL. If it wasn't for that, I'd still be using MySQL for my company's application since I'm more familar with it.

    Anyways, PostgreSQL IMHO has some things going for it:
    - More features like triggers, stored procs, schemas, subselects, etc then the current stable version of MySQL supports. About the only thing I find myself using are subselects which are just a nice to have.
    - Attempts to be "safer" with your data via WAL, etc. Good for unreliable environments.
    - Tends to follow the SQL standards closer then MySQL
    - Is BSD licenced so you don't have to worry about licensing issues.
    - #postgresql on freenode is great. The people there are intelligent, knowledgeable and friendly if you're not an *sshole. They've helped me a lot.

    The problems I have with PostgreSQL is that:
    - INSERT is very slow (about 3x slower compared to MySQL/InnoDB) for my dataset. The "answer" is to use the COPY command or disable your indexes/FK's which is f*cking lame since you loose all your relational integrity. I was willing to trade off performance for disaster prevention (system crash, power failure, etc) by disabling WAL, but you can't actually do that.
    - The OSS tools available aren't as good for postgres as they are for MySQL. I've yet to find anything as nice or complete as phpmyadmin for Pg or something that supports schema's for ER Diagrams. Frankly, I'm sick and tired of designing my DB in vim.
    - Having to run vacuum all the time to help the query optimizer figure things out. Why this doesn't happen automagically in the background without me having to worry about it is beyond me.
    - In general, I find the documentation on mysql.com superior to on postgresql.org, but #postgresql more then makes up for it.

    Frankly, all the technical "problems" in MySQL or Pg can be worked around if you're willing to think out side of the box.
      • Re:Popularity (Score:5, Insightful)

        by mellon (7048) * on Monday September 05 2005, @02:21PM (#13484648) Homepage
        MySQL is like Microsoft. It's not entirely compatible with the standard, but everybody is using it, so if you want to use their software, you have to use it too. I have a copy of PostgreSQL and a copy of MySQL on my server, because Wikipedia doesn't work with PostgreSQL. I presume this is because the developers started working with MySQL back in the bad old days when it was _really_ incompatible, and their code now contains dependencies on MySQL.

        I don't really know what to say about all of this - these incompatibilities are really frustrating as an end-user of this software, but I understand that it's hard to make things work with both MySQL and PostgreSQL, and resources are limited. What frustrates me is that these incompatibilities create a form of lock-in - once you've based your app on MySQL, you are stuck with it.

        I suspect that if you were to start now, and to use the SQL spec rather than the MySQL documentation as a reference while doing your development, you would wind up with something that was a lot more portable, so this isn't actually an argument against using MySQL. It's more an argument towards sticking to standards when using whatever db you choose, so that when the time comes to use a different DB backend, you aren't faced with a monumental refactoring job.
        • by Billly Gates (198444) on Monday September 05 2005, @02:44PM (#13484798) Homepage Journal
          The one good thing I have to say about mysql is that its multi-user friendly for hundreds of accounts.

          For a mom and pop ISP with only 3 or 4 employees this is significant. Is it feature filled? No

          Its just included in the default user account which is difficult if not impossible with posgresql unless you manually install it for each account.

          Users on the web dont need something heavy unless they are a commercial website. Also there are a ton of php and perl scripts and tools for users to use.

          This is why msql is so popular. Its what ISP's prefer.

      • Re:popularity (Score:5, Informative)

        by Bloater (12932) on Monday September 05 2005, @02:23PM (#13484663) Homepage Journal
        MySQL's biggest problem is that if you try to update or insert with invalid data, in many cases it successfully inserts wrong data. PostgreSQL doesn't do that.

        PostgreSQL has this nice Object-Relational model where tables can be derived from each other, but there are some nasty bugs that mean I think those features are still best avoided.

        Overall, though, I think PostgreSQL is by far the better RDBMS.
    • Re:My point of view (Score:5, Informative)

      by scrutty (24640) on Monday September 05 2005, @02:38PM (#13484754) Homepage

      There is no postgresql release 7.5. The last 7.x release was 7.4 , the current stable is 8.0 with 8.1 in beta.

      • Haw haw (Score:5, Informative)

        by Safety Cap (253500) on Monday September 05 2005, @02:57PM (#13484874) Homepage Journal

        Parent is comparing non-current versions, and making up false "cons" for mysql, out of thin air...

        5.0 has views, triggers, stored procedures etc, and it's still amazingly fast.

        So, if I try to insert, say, a string of 10 chars into a varchar(9) field, what will it do? Will the magic version 5 reject it, as ever real database does, or will it truncate it silently, just as Toy databases (ala MySql 4.x) are wont to do?

        What about the whole not-null thing? You know, if a field is set to NOT NULL and you don't populate it when you insert a row, a real database will reject it, where as a Toy database will accept it (MySql 4.x again!) and populate it with ... some other value.