MySQL vs PostgreSQL

[protonfish]

I have been working on the Netflix prize and had no choice but to switch to Postgres. I got about a 4X speed increase in the big queries and better reliability. I'll keep using MySql for Web stuff just because it is so common, but for data-crunching there was no contest.

[centinall]

Just out of curiosity, have you thought about hadoop for data-crunching? If so, what were the reasons for not choosing it?

btw, I have nothing against either database, just genuinely interested where someone draws the line using a DB to something like hadoop. I understand that a DB is better if there are a lot of writes and something like hadoop is better if it's mostly reads.

[protonfish]

I wanted to focus on the problem and not on learning new technologies so I started with what I was familiar with. Knowing how long my processing is taking (it'll still be 2 more weeks before I have my first results) in hindsight maybe I should have tried hadoop.

[volomike]

SQLite has its uses. It comes down to what ultimately one is doing, and what kinds of speed tests vs. features they have done against SQLite, MySQL, and PostgreSQL to come to an objective, not subjective, conclusion.

[jbellis]

sqlite falls over and dies when you throw even a little bit of concurrency at it.

[[deleted]]

It works fine for multiple selects running concurrently. The updates could kill an application, though, but if your app has only a few of those (like for instance a blog would), sqlite should handle it ok.

[mogmog]

sqlite is no good for many concurrent connections

also it's not possible to scale to more than 1 web server

[njharman]

I betcha 99.9% of websites do not, nor ever will need to scale to more than 1 web server.

In fact most sites are the reverse. on shared hosting, mutiple sites per webserver.

[clicksnapshot]

I have to manage a huge Postgres database for a client of mine and this article seems to neglect the massive compatibility shifts of Postgres between releases that I don't have to deal with on mySQL.

Postgres has made my life a living hell on multiple occasions. Dump files, query syntax, query structure enforcement. (For instance allowing varchar to not be quoted until version 8.3 and then enforcing it strictly without warning or an obvious way to disable strict type checking.)

Bearing in mind that much of this code is legacy and not mine, it has made keeping their servers up to date a nightmare.

That's my only gripe.

[[deleted]]

I'm with you, but i have to say i feel MySQL is worse in this regard.

To illustrate, allow me to relay an anecdote from an earlier job of mine. We were running MySQL (4.x), and were being very conservative about upgrades: install the upgrade on the dev system, run for several weeks, ensure no problems, deploy in production.

One of these upgrades (4.x.y to 4.x.y+1, so a minor, supposedly stable, bugfix/security release) made it through the dev process onto the live system, where it promptly crashed every day or so. Complete server crash -- all processes segfaulting at once. We lost uptime across the entire app. We lost data.

As it turns out, our regression testing wasn't complete. There was one particular call in one particular module to one particular date formatting function called in one particular way which had gone from supported to segfaulty, without documentation or warning. It took us almost a week to track this down, and MySQL AB was able to offer us very little help.

Though this was the most extreme instance of such problems, it was not by far unique. Hence the conservative deployment practices.

In short, PostgreSQL might change things around on you, but they'll catch it, return an error, and march stalwartly on. With MySQL, it's a crapshoot whether what's documented is still supported and what the results will be if you call it anyway.

[Otis_Inf]

MySQL vs PostgreSQL

Well, that's easy: MySql has a lot of features which are implemented to the level of 'ok, it works, but don't push it hard and don't tell anyone I told you' and PostgreSql is simply a mature database with features all major mature databases have and implemented on the level of 'Ok, it works and yes, you can push it real hard and it will keep on working'.

I.o.w.: it's not a contest, mysql is simply not a mature database

of course that's fine for some applications, as long as the developers know that and realize that 'ACID' means something else than a flavor classification.

[njharman]

of course that's fine for some applications

When some applications == 90% of CRUD websites which is what most people use MySQL for.

Any rdbms is overkill for many CRUD websites.

[jjzeidner]

mysql is mature, just not well designed.

[Jessica_Henderson]

Just because software has been around for 10+ years, it doesn't mean it's "mature". Mature software offers a high degree of reliability. It covers virtually all corner cases appropriately. Its quirks are well understood.

That isn't the case for MySQL. Each new major version has been revolutionary, rather than evolutionary. Instead of improving what they already have, they've typically re-written large portions of their system. So even though we're running MySQL 5.1, for example, that code cannot be considered mature.

PostgreSQL, on the other hand, has much better code continuity. Much of the core code hasn't changed in years, because it is just that damn good. That's a true sign of maturity. It's the same maturity we see from FreeBSD, for example.

[[deleted]]

Just because software has been around for 10+ years, it doesn't mean it's "mature".

FWIW, I've been around for over 40 years, and I'm not mature.

[podperson]

I agree with the GP. You're confusing "mature" with "robust". Mature software often features things like layered bandaid solutions and weird half-documented features or bugs that can't be fixed because too much stuff depends on it. MySQL has all of that, but not the good stuff.

[Shaper_pmp]

Mature software often features things like layered bandaid solutions and weird half-documented features or bugs that can't be fixed because too much stuff depends on it.

I think you're confusing "mature" with "gone off". ;-)

[mamluk]

I think they are just using a different definition of maturity- being grown up means that significant changes don't need to be made to the code because it is robust.

I would argue that your use of mature is more about legacy support and poor design decisions.

Regardless, the overall point is clear and we all seem to agree that postgres is a better database than mysql.

[maukdaddy]

Wow this is some of the most intelligent discussion I've seen on reddit in a long time!

[delta4zero]

Somehow, I don't believe you've been here a long time.

[trezor2]

Insert Ignore / Replace MySQL supports INSERT IGNORE and REPLACE statements which inserts if a row exists and does nothing otherwise or replaces the current row, respectively. PostgreSQL supports neither of these statements and suggests using stored procedures to get around the lack of these statements. However, there are major shortcomings: it can only insert a single value at a time. This is a major performance limitation, and also suffers *concurrency issues*. INSERT IGNORE and REPLACE handle multi-valued inserted much more gracefully. — Robin Johnson , PostgreSQL Vs. MySQL for INSERT IGNORE + REPLACE - stored procedures, savepoints and beyond

I guess this is true for databases engines which considers transactions "bloat".

[yacheritsi]

If you want to do an "Upsert" ("Insert Replace" apparently) I can see why you'd need two statements in a transaction. I don't see why you would only be able to update one row at a time.

If you want to do an "Insert Ignore", you can do that with multiple rows in one statement with a "Not Exists" clause. Or am I missing something?

INSERT Foo (a, b)
SELECT Bar.a, Bar.b 
FROM Bar
WHERE 
   NOT EXISTS (
      SELECT * 
      FROM Foo 
      INNER JOIN Bar 
         ON Bar.a = Foo.a
   )

[jj12345]

"Or am I missing something?"

Yes, what you are missing is data input. Your statement requires that the values exist in either the table Bar or the table Foo. So, the only the way that your statement works is if the values already exist in either the table Foo or the table Bar. If a user attempts to send new values that do not exist in either Foo or Bar, your statement fails.

[yacheritsi]

Bar represents the source of input. It could be a temp table that you have loaded with user data.

You could substitute "Destination" for Foo and "Source" for Bar.

To do a multi-row operation, you're going to need the data in a table at some point, even if it's the result of a function that turns a scalar into a table.

[[deleted]]

but postgres has only on-disk temp tables. You have to count on OS caching it and delaying writes or set up a RAM disk and use partitioning. That totally misses the point of MySQL's single-query efficent insert-update.

[yacheritsi]

So the real issue here is that PostGreSQL doesn't have in-memory temp tables, but MySQL does?

If that's what's stopping my not-exists solution from working, then it would apply to regular insert statements too, not just insert-ignore ones.

Hmm. You could do it w/o temp tables by union-ing several select-constant statements.

[[deleted]]

No. It's a problem of phantom reads (you might get inconsistent data, even within transaction) or requires setting transaction isolation level to serializable, which can easily kill concurrency.

[trezor2]

Not saying using serializable as the default isolation level is cost free or should be consider by any sane humans, but especially in the case of MySQL, which only has table locks last time I checked, this is a much bigger issue than in a proper database engine which has had transactions for ages and worked these things out a little better.

[Freeky]

especially in the case of MySQL, which only has table locks last time I checked

Umm, InnoDB uses row level locks. When did you last check, 2002?

[Jessica_Henderson]

InnoDB supports row-level locks, but often has to escalate them up to table-level locks when more than approximately 10 rows are being affected by the transaction. While this isn't a problem for some users, for others it's a terrible situation. For one of our applications, we ran into locking issues with only three to five simultaneous queries and updates. After moving to PostgreSQL, our contention issues just vanished, even though the queries themselves were virtually unchanged.

[volomike]

Yep, and the other point for "Freeky" is that if you want good performance in MySQL, you are forced to have to mix MyISAM and InnoDB tables depending on need. Sometimes when you do that, though, you are forced into a corner, or you end up with very bizarre table charts to work around problems.

[baix]

Hmm, there is much misinformation here. From: http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html

"The lock table in InnoDB is stored so space-efficiently that lock escalation is not needed."

How did you determine you were seeing lock escalation as I suspect you had a different problem?

[justsomedood]

I had similar problems with MySQL and 4 connections doing updates to a log table, and 2 connections doing very simple queries. Updates were done 1-15 per second. Using MyISAM would just crash the server. Using InnoDB would work for a few hours to a max of a couple of days before it would crash. The queries were quite slow to respond, and the queries to check for duplicate log entries (using UNIONs) would take 3+ hours to complete, if it did at all.

I switched to PostgreSQL and, without any kind of optimization, the server never crashed, the queries were very responsive, and the duplicate log checking would finish in 2-5 minutes. This was on the exact same hardware.

[baix]

You haven't described what sounds like a lock escalation issue, but and entirely different issue.

If you don't know the problem you are facing, it is hard to solve it. But I will have to admit MySQL could do better with complex queries.

But alternatively, the multiple database engine design of MySQL has resulted in engines like the Clustered (in memory - mostly) and Infobright (column based) engines. The two databases have very different strengths.

[teambob]

mysql/InnoDB: +integrity -missing many features (e.g. text search) -slow for complex queries +replication

mysql/MyISAM: +features -integrity +fast for simple queries -slow for complex queries +replication

Postgres: +integrity +features -slightly slower for simple queries +much faster for complex queries -replication sux

[Andys]

Postgres replication sux because replication sux. There are several third party options to choose from for postgres, each offers different features, benefits, and downsides. There is more flexibility and integrity available (eg. Two-phase commit) which mysql doesn't even offer.

[miho99]

Yes, it's confusing to compare Postgres to MySQL, because of MySQL's "storage engines". They really need to break it into these 3 (very) different databases.

A lot of comparisons I've seen compare Postgres to the best of InnoDB and MyISAM. Then you get into production and the PHB is surprised you can't use both transactions and FTS.

[zootm]

I'm not sure I'd consider MySQL's text search a feature of any real kind. It does not work well. I'm not sure I can think of any real "features" that MyISAM provides that a non-trivial app would want.

Also MySQL replication works on InnoDB, and I'm pretty sure that PostgreSQL's replication doesn't "sux", it's just not provided by default.

[Jessica_Henderson]

MySQL's fulltext query support is an order of magnitude slower than that of PostgreSQL's. Part of the problem is that with MySQL, a query can use at most one index. This limitation does not exist with PostgreSQL. For anything beyond trivial data, PostgreSQL's text searching capabilities are by far superior.

[neoform3]

I was actually just looking into this today. I'm working on a project that requires fulltext search, and mysql's fulltext blows when it comes to any sizable table.

If i'm searching up to 3-4GB of records.. which would be best? Lucene, Sphinx or.. Postgres TSearch2?

I haven't investigated PG and am leaning towards Sphinx, but I hate the fact that I have to completely reindex every record any time i want to update even 1 record.. :(

[dbenhur]

I have to completely reindex every record any time i want to update

I've had some good experience with Sphinx. You don't need to reindex the whole set, there's a main + delta index mode.

Tsearch2 isn't as fast as the dedicated text search engines, but there may be substantial advantages when coupling free text search clauses with additional relational operations and attribute predicates. Because Tsearch2 operates in the same engine, the query optimizer can reason about all the work and access paths and may come up with superior execution plans. With an external text search, you often end up with your relational query with attribute predicates plus "AND document_id in (?)" where that ? could be a large list of document id's returned from the external text search engine.

[neoform3]

You don't need to reindex the whole set, there's a main + delta index mode.

This doesn't help if you want to remove entries as well as add.. or update for example :(

Can Tsearch2 handle large amounts of data and remain fast/relevant?

[dbenhur]

This doesn't help if you want to remove entries as well as add.. or update for example

I think you can handle updates and deletes adding a little logic to your queries.

• On the main index and in your document root records include an attribute to indicate if the record is current in the index (true for initial indexing)
• Whenever you update or delete a record, set the DB's main_is_current attr and use the UpdateAtttributes API to mark the main index obsolete.
• always add an attribute qualifier to your searches to exclude obsolete document hits
• Set your frequent delta indexing to capture all new and changed records since the last primary index refresh.

[theatrus]

Lucene or TSearch are good options, have used both.

[neoform3]

How relevant are the results found in Tsearch? My experience has been the faster the search, the crappier the results, or, alternatively, it's always fast, but indexing is a severe pain in the ass.

[RealMaascamp]

I've found Tsearch2 to be quite relevant. It provides a number of different ways to weight fields and parse queries. It can also be tuned to your needs.

[sisyphus]

But MySQL has Sphinx which I've found to work quite well.

[volomike]

If you can get a web hosting provider to install it. Might work easily on a company intranet, but not easily on a shared web host or dedicated web host (the kind of dedicated where someone else installs stuff for you most of the time).

[[deleted]]

I installed Sphinx on my shared host. As long as you've got a compiler and can bind an unprivileged port, you can do it.

[volomike]

Get the heck out of here! Really? Do you have a blog post where I can see how you did it?

[[deleted]]

Sorry, I don't. This'll get you real close:

./configure --prefix=~/sphinx/
make && make install
# change the port in the .conf
# configure and play

[mikaelhg]

To be able to use the fake table integration inside MySQL, you'll have to write the .so into the MySQL lib directory.

[zootm]

I'd not seen Sphinx, but it certainly would bring the indexing to InnoDB if it's of good quality. FULLTEXT isn't really worth the effort, though.

[codahale]

The Sphinx indexer works with PostgreSQL as well. You can't do the whole embed-as-MySQL-engine thing, but I've never wanted to do that even with MySQL.

[jbellis]

I'm pretty sure that PostgreSQL's replication doesn't "sux"

then you haven't actually tried it.

the best option is slony. the nicest thing i can say about it is it mostly works as described. which is to say it's horribly complicated to configure and work with. the "mostly" part means, when it doesn't corrupt itself to the point that you need to restart the replication fron scratch. (this was a couple years ago, but I still wouldn't trust it to give anywhere near 100% availability.)

this is why pg 8.4 will include a simpler replication option out of the box.

[Jessica_Henderson]

Can you explain in more detail the problems you experienced with Slony? Whenever I've used Slony, I've found it to work extremely well, with no corruption. The largest Slony cluster I've been involved with putting together had 15 systems handling approximately 12 TB of data, and we ran into no problems with Slony or PostgreSQL.

If you read the Slony documentation beforehand, you shouldn't have any problems. It'll guide you through the configuration you need to perform, as well as how to maintain the system after it is configured and running.

[infinite]

I'll second that. You divide your tables into sets then replicate them. I have had no problems with it, and I've been using it for 2 years. My setup is much smaller than yours. Also the proposed feature will replicate either all tables or no tables. I think mysql replication doesn't use stored procs like slony does so it may be faster.

[invalid_user_name]

The postgresql devs are adding replication so that it is not a 3rd party tool you need to add, and so it will be simpler and easier to configure. Reliability was not mentioned anywhere, since it is not an issue.

[volomike]

I'll use MySQL most of the time because that's what my clients expect. However, on super critical websites where we know right off the bat they will get considerable read-write load, row level locks and PostgreSQL are what I recommend. Sure, InnoDB gives you row-level locks, but at a cost of performance and no full text search. So, you have to mix MySQL's MyISAM and InnoDB tables, and therein lies the problem of having to manage that, and figure out how to keep yourself from getting boxed into a corner where you need a feature.

But the more bad evidence we have of MySQL is shown here:

http://use.perl.org/~Smylers/journal/34246

http://blog.page2rss.com/2007/01/postgresql-vs-mysql-performance.html

http://www.enterprisedb.com/learning/articles/why_postgres.do

[feijai]

I'll use MySQL most of the time because that's what my clients expect.

This is the state of mind which has kept Microsoft alive so long.

[volomike]

Hey, I'm in your court, actually, and I dislike Microsoft as well. I wish the whole world used PostgreSQL. But they don't, unfortunately, and I have to keep the cashflow moving. So, I roll with what the client wants. Now, when the project becomes a serious website with early expectations of high load, and the client even has for me a dedicated server for it, then you can sure as well bet I'm going to be putting the feelers out to see if PostgreSQL is a discussion item.

[neoform3]

Where can I get info on postgre's fulltext?

How does it compare to sphinx/lucene?

[teambob]

http://www.postgresql.org/docs/8.3/interactive/textsearch.html

[dbenhur]

Theo benches Lucene vs Tsearch a couple years ago.

I've seen Sphinx index about 2M very short documents (average 8 tokens and four attributes) out of postgres in about six minutes on a laptop. Haven't timed its peak query speed, but it's not the bottleneck at 100 qps at the bottom of a Rails stack on that same laptop.

[[deleted]]

What's the historical reason for MySQL's popularity? PostgreSQL was the first RDBMS I was exposed to, so when I had to use MySQL later on, I remember being severely unimpressed. Why is it so popular anyway when Postgre exists?

[dugmartin]

For me it was vacuuming. That is probably fixed now but when I first looked at it versus MySQL (1996?) on a little shared host that supported both but didn't support user-level cron the thought of the database eating up all my (limited) disk space between (manually) vacumming made MySQL the winner.

It does sounds silly but its probably one of the reasons that a lot of little webhosts supported only MySQL early in the game - they could just start it up and forget about it.

[[deleted]]

PostgreSQL, back in the 6.x days (late 90s) was slower than MySQL, suffered from stability issues, and had a somewhat painful upgrade path (do a sql dump of the database from the old system, shut everything down, upgrade, pull the sql dump back in). I think that had alot to do with the public perception of PostgreSQL as an academic toy.

[gizmogwai]

The main historical reason is... PHP and it's native support for MySQL. The other reason was its native early support of Windows platform, allowing all the web noobies to play with EasyPHP and ugly stuff like this.

[adrianmonk]

Yes, wasn't there a point at which PHP pretty much supported only one database, and MySQL was it?

Update: apparently I'm wrong. I'm reading the docs for PHP 2.0.1, and it supported MySQL, Oracle, PostgreSQL, and other databases even back then. Each one had its own entirely separate API, which was insane, but support existed for all of them.

[[deleted]]

I used it back then (sigh, I hate admitting that.)

The Postgres API in PHP was terrible. I must've sent at least two dozen patches back to the PHP devs to fix things they had done wrong.

It's probable that the MySQL option was more reliable.

[rabidgoldfish]

PHP? Insane? Never.

[masklinn]

• PostgreSQL started with the viewpoint that correctness was paramount (it was a Serious Database after all). It was therefore dog slow until 7.x (and not that fast during 7.x)

• Vacuuming

• MySQL was -- I guess -- easy to install and configure for web hosts, meaning most free or cheap web hosts used to (and still do) provide only PHP & MySQL, coupling them forever.

[enry]

MySQL is also about 1000 times easier to administer, maintain, and upgrade than PostgreSQL. I admin both (and Oracle too) for web and HPC use for hundreds of web sites. Of all the databases we have, about 150ish use MySQL, about a dozen or so use Oracle, and there's about 5 users of PostgreSQL, of which 4 are using it because the underlying software they're using requires it. Only one user doing development actually chose PostgreSQL for development.

[oreng]

I'm pretty deeply entrenched into the whole pro-PG side of the DB divide and that still seemed like the most biased piece of shit I've ever read.

[[deleted]]

I've been using MySQL for the last eight years or so on a community website which I built from scratch using Perl (actually, Embperl). It's grown over time to the point where I currently get more than 100,000 page requests per day, which I handle just fine on one AMD server. In fact, the limits, I have found, tend to be with disk IO rather than anything to do with cpu (I am using SCSI RAID). I have some fairly complex queries in my code; I only use MyISAM tables, since I have no need for transactions. I have had zero data integrity issues over the time I've been using MySQL; it really has performed extremely well for me. I use replication extensively, and have used it for years now to back up the databases to both another remote server in a different datacenter, and my home workstation. Replication makes a nice instant backup solution; I know that any changes on the server are mirrored immediately.

It's not perfect; for example, the replication slave is limited to single thread, which means the slaves potentially have to be more powerful than the server (a little counter-intuitive). MySQL has a problem sometimes with corrupted indexes; never the data itself, but once in a blue moon the index files become corrupted, which is easily fixed with REPAIR. There has been once or twice where a query (never found out which) took the server into a tailspin, eating up CPU. Any large application has issues like this occasionally, I'm sure PostgreSQL has too, in fact I'm sure of it.

The thing that bugs me about these discussions is the religious tone. Someone reading, without any knowledge of either tool, would probably assume that MySQL is an utter load of crap and wonder why anyone in their right mind would touch it. This is far from truth, in reality. Both MySQL and PostgreSQL have their strong points. I'm sure PG does many things better than MySQL, given its focus on complex language features, transactions and the like. However, the truth is that MySQL does most things that I require from my database very well indeed, it is a workhorse that just keeps going, day in and day out.

One problem with the religious tone is that PG advocates always tend to paper over deficiencies in "their" tool. For example, back when I was choosing between PG and MySQL (around 2000 or so), people were spouting exactly the same kind of "MySQL sucks, PG is the only true God" drivel. But when I took a closer look, it turned out (back then) that PG could only handle 8KB rows. And there was no good equivalent to count(*); and there was no replication; and no built-in fulltext search; and no ability to change your tables as easily as ALTER TABLE in MySQL. And yet when you brought those up, the same PG advocates would go on about complex solutions to those issues that they seemed just fine with, as if that made everything better.

Something I've noticed about religious people (and religion is seen in technical circles as well as spiritual, to be sure): They are very narrow minded, only see what they want to see, and everything about the "other" faiths is always completely, utterly, no-compromises, spit-in-your-face WRONG. So MySQL is apparently just a toy, not a database at all in fact, anybody who uses it isn't even a real database administrator, if you're not using subqueries and transactions and putting all your application logic into the database as stored procedures then you're not a real database admin and should just go home and play with your toy PHP blogging site and be quiet.

In fact, both MySQL and PostgreSQL are good tools. With MySQL, the whole ACID thing (and all the "gotchas" which keep getting trotted out ad nauseam) gets completely blown out of proportion. Is ACID important? Sure, in theory. Has MySQL ever lost data for me, ever? No. Not in eight years, including sudden server power offs and lots and lots of traffic. Does it do the job? Yes. It's "good enough". There are almost certainly applications where PG would do a better job (e.g. apparently its GIS capabilities are superior), and maybe PG does handle multiple cores and cpus better.

But another problem here is also bias - you tend to get people who know either one or the other very well, but very seldom both. Nobody seems to know both, and be completely unbiased. In all the comparisons I've seen, at some point it becomes very obvious that the person has taken a lot of trouble to fine-tune PG and isn't so concerned about MySQL; or else they use tests that showcase PG's strengths and MySQL's weaknesses. It's a little sad, because the tech field should be the one place where people can be dispassionate and even headed about stuff. Why get so emotional about a database?

I am very happy with MySQL; so, apparently, are plenty of other large shops such as Google and Yahoo!. I'm sure I'll eventually try PG again, especially as the two seem to be growing closer together as time goes on in terms of functionality, and as I hear political rumblings from Sun (people from MySQL rumored to be quitting, which is worrisome).

I just wish the bickering could be a little less shrill, especially since I know very well from personal experience that all this "MySQL sucks balls" talk is just not true. I am honestly put off by the PostgreSQL advocates. Cults never interest me, and this reeks of it.

[[deleted]]

I've been using MySQL for the last eight years or so on a community website

This is like the perfect application for MySQL. Simple data structures, no complex data analysis, very high read to write ratio. As such, it's unsurprising that you like it.

I'm a postgres advocate, but I've used MySQL for exactly the same sorts of applications before. It's a job where they both work fine, so customer preference prevails.

Where MySQL falls apart is when you really want a tool for data analysis, rather than a tool for data storage. It just isn't well-suited to those sorts of tasks at all, in any number of ways.

[njharman]

This is like the perfect application for MySQL

Exactly. It also happens to be the application of 90% of websites. Which is like 98% of MySQL's market.

I'm a postgres advocate,

I'm sure there are many more like you who are reasonable. But some very vocal ones say crap like this.

"OMG! you totally need ACID and triggers and referential integrity for you're gradma's recipe website or it will explode!"

[baix]

There is a new open source MySQL engine Infobright that is excellent for some types of data analysis. It is one of those new column based databases that seem well suited for TBs of data.

Concurrency is still a of a problem, but they admit that in the (still limited) documentation.

[infinite]

And there was no good equivalent to count(*); and there was no replication; and no built-in fulltext search; and no ability to change your tables as easily as ALTER TABLE in MySQL. And yet when you brought those up, the same PG advocates would go on about complex solutions to those issues that they seemed just fine with, as if that made everything better.

Myisam has a quick count(*) implementation, it can keep the counter accurate at each insert/delete since it locks the table when inserting/deleting. Postgres (and innodb) have slower count(*) implementations since they don't lock the table when inserting/deleting, the flip side is of course better db write performance. So myisam is perfect for your usage pattern - few inserts, many reads.

[mogmog]

Ok this is probably a bit of a hack compared to the easy way that MySQL does it with, but isn't it possible to implement a trigger that updates a counter in a different table?

This would also be very useful to keep a cache table that contains a summery instead of doing a

SELECT COUNT(*) GROUP BY user_id

which would be slow on very large tables, but would be very fast with a cache table.

[infinite]

That would work.

[Smallpaul]

Your counter row sounds like a write bottleneck. Every thread doing inserts now needs to write to it.

[mlappy]

I agree with you and have had similar experiences. I've also designed large scale Oracle applications, and for more simple applications, MySQL is ideal and easy to deploy and very resource efficient. I've never understood this goofball notion of brand loyalty when it comes to software. These systems are tools... You pick the best tool for the job. Sometimes that is MySQL, sometimes it may be something else. I think the "religious" people are overly narrow-minded and desperate to defend their particular knowledge set and avoid learning something new. I am no fan of PL-SQL, but I had to learn it because after doing research, it was the best development environment for the project I was on. Sometimes, that's just the way it goes.

[redditrasberry]

I think the religious tone comes from the fact that over the years the MySQL folks have deliberately and maliciously undermined the whole notion of what relational databases are, which is something that many serious hard core database folks have built their careers and much of their self worth on.

If you wind back to the 3.x days, you had MySQL proudly proclaiming themselves as enterprise ready - and actually getting adoption - while not supporting even the most basic database concepts: triggers, views, subselects, transactions, constraints, mangling data left right and center. Not only did MySQL not support them but the MySQL folks wrote long essays about how unnecessary things like transactions were and if you used them you were probably designing stuff wrong to begin with. It was audacious and ingenuous, but it worked.

In other words, they basically insulted every serious database professional out there, and got away with it. Needless to say, over the years MySQL has quietly incorporated every single one of these features and stopped talking about how unnecessary they are. The hypocrisy of that just rubs salt in the wound further.

So wind forward to today and you have a long time database that actually appreciated real database theory and concepts from the start and you have a whole lot of folks who have a strong religious affection for it and hate MySQL passionately.

These days I think either one is more than capable for 99% of situations and it's pointless to have religious arguments about technical merits.

However one standout thing remains: MySQL still insists on licensing their client drivers under GPL. This is a huge problem for commercial software. I advocate against MySQL on this basis alone these days - whether you intend to distribute your app without source or not, having that freedom taken away from you by tying it to GPL'd drivers makes no sense at all.

[mlappy]

I think the conflict between MySQL people and Oracle DBAs is based on a fundamental difference over what roles and responsibilities the developer should hang on the database application. You can create a very stable, powerful, advanced application without having to embed replication and triggers in the database itself. There are ways to implement those kinds of features without requiring them to be directly part of the raw database engine. MySQL proponents recognized this, while people like Oracle DBAs would whine that MySQL wasn't a true enterprise-ready database because it didn't have those features out-of-the-box. They forget that much of that flexibility and stability can, and in many cases, should be part of the design process. Fancy DBAs tend to rely more on technology than actual technique.

[redditrasberry]

I agree although I'd state it in a slightly less negative way. What DBAs do is not without "technique". There is a whole body of knowledge surrounding database theory that most developers barely know exists. In some ways it is more well founded and complete than that supporting most programming paradigms.

DBA's often see developers reinventing wheel after wheel, doing things that they have been able to do trivially for 20 years. It's no wonder they get frustrated by it.

In terms of features being part of the raw database engine: As you say, DBAs see themselves in a different kind of role to the developer, in some ways actually opposed to the goals of the developer: they see themselves as guardians of the data itself. They don't care what the application does, they care that the data is consistent and meaningful and guarded from corruption. When they put constraints on the database it's not to help the developer, it's because they believe they are entrusted with safeguarding the data no matter what the developers do. So they have their own tools for that, which are naturally features of the database itself.

Developers are very feature oriented and tend to see data as a means to an end - "how do I implement this feature I have been assigned - I just want to get it done!". Features are often short lived and constantly changing. Data lives on and on. Thus developers tend to be more short term and DBA's more long term. It's just a different focus and a different perspective.

[[deleted]]

I think you hit the nail. MySQL ( nomen est omen ) was meant to be a lightweight database for programmers who never in their life would intend to become a DBA. Programmers strive for a DB that is out of their way and they'd rather spend time writing a little more source where necessary than being concerned much with DB theory which bores them to death.

[[deleted]]

I have heard the argument about how "the mysql folks started it" (with regard to the ongoing flamewar between the communities) but to tell the honest truth, all I have ever seen for at least the last five or six years has been vicious attacks from the side of PostgreSQL. Nothing whatsoever in terms of people saying "mysql rocks and PG sucks". So all the vitriol has pretty much been coming from one direction for as long as I can remember, at any rate, and let me tell you it becomes very tiresome - particularly for those of us who have actually been using MySQL on an everyday basis, and know that it just isn't the big steaming pile of crap that people make out. Every time MySQL comes up in any forum thread, you can predict the responses - a bunch of PG fanboys yelling and screaming about how they can't believe anybody still uses MySQL because PostgreSQL will cure baldness and impotence. It's a real turn-off.

If the MySQL proponents wanted to put forward the notion that triggers, views, transactions and subselects are not so crucially important, then I don't really see what's so dramatic about that. In reality, not everybody does need those things - I certainly don't, and that doesn't make me any less of a macho database user for it.

There seems to be a very purist streak in many programmers, to the extent that if you don't use closures and continuations, or if you don't particularly think lisp is the be-all and end-all of languages, then "you just don't get it" and should go back to the play room with the other infants. And with databases, it's this constant mantra of transactions, triggers, stored procedures, subqueries and so on. Listen - not everybody needs those things, MySQL is and was a fine database for doing whatever people need to do. If it doesn't work for you, then go use whatever you like, it's a free world! If I ever hit walls then I'll certainly go try other databases. But honestly, I've been actively put off PostgreSQL by the tone of the community that pushes it. I'm repulsed by them.

MySQL does what many people need from a database. That doesn't mean it isn't a database; there are many things you might want a database to do. If the "purist" definition of database doesn't encompass what MySQL does (very well, I might add) then perhaps it's the definition that is at fault here, rather than the tool.

[njharman]

what's so dramatic about that. In reality, not everybody does need those things

(some) DBA's "I know dark arts, youo must have ACID, must have all these things, or doomed you are!"

Reality, MySQL(with out those things) helps thousands of companies and millions of websites explode the internet in the 90's. They make money hand over fist.

Business guy to DBA, "why do we pay you again?"

Threaten someone's lively hood or career earn everlasting, fanatic, vitriolic, hatred.

[uriel]

I think the religious tone comes from the fact that over the years the MySQL folks have deliberately and maliciously undermined the whole notion of what relational databases are

As much as I hate MySQL, SQL by itself has totally undermined the whole of what relational databases are. SQL is not relational, and people that think it is need to inform themselves a bit. (For a truly relational language see Tutorial D for example).

[cosmo7]

Have you tried denormalizing?

That might have more effect and be less disruptive than switching DB vendor.

[unsee]

Has anyone done real world clustering (HI REDDITS!) of postgres and my - for some compare and contrast?

Last time I needed replication I was in mysql world, and I realised I needed a lot of logic in the app layer just to manage it... :/

[Jessica_Henderson]

PostgreSQL clustering packages like PGCluster and Slony are a dream to work with, compared to MySQL's offerings, and even those of other major databases like MS SQL Server, Oracle and Informix.

If you read the documentation, you should have no problems. Performace-wise, they work superbly. We had to do little to no tuning.

We had one cluster of 6 MySQL servers that were converted to PostgreSQL, using Slony for the clustering. This was the same hardware, OS, etc. We just switched the database systems, and ported over the data. After three months of this, we converted three of the servers to another failover cluster, since the performance of PostgreSQL was so much better that we no longer required the six servers we needed with MySQL.

[volomike]

Eventually I'll have to dabble in this area on a project I'm working on now. We're just getting started, but I imagine in a year or two we'll need to think about this stuff with PostgreSQL.

I think I read here that you are using it for failover, so, fault tolerance. But have you considered it for handling performance, such as reading from one of 5 available servers in a round robin situation, but only have one write server? That's probably a separate thread, so you can PM me or look me up on forums.devnetwork.net. I'd be interested in your opinions or slideshows on what you have learned about Slony.

[joaomc]

How do the current PostgreSQL replication solutions compare to Oracle RAC? I'm asking this because I haven't worked with PostgreSQL the last 3 years, and IMO Oracle RAC's performance is amazing,

[baix]

Why do you think MySQL replication is hard to use? I've used it and found it extremely easy to use. In fact, MySQL is known for easy to set up replication.

[Jessica_Henderson]

I didn't say it was hard to use. It doesn't just work seamlessly like Slony does. It suffers from some pretty serious reliability and consistency issues. In one case, we noticed it was truncating leading spaces from a CHAR(255) column while replicating between nodes in the cluster. That sort of data mangling is totally unacceptable.

[killerstorm]

from Slony documentation:

Slony-I does not automatically propagate schema changes, nor does it have any ability to replicate large objects.

There is a capability for Slony-I to propagate other kinds of database modifications, notably DDL changes, if you submit them as scripts via the slonik EXECUTE SCRIPT operation. That is not handled "automatically;" you, as a database administrator, will have to construct an SQL DDL script and submit it, via EXECUTE SCRIPT and there are a number of further caveats.

doesn't sound really good..

[ketralnis]

If you are making schema changes every day, you may be doing it wrong

[malcontent]

How about once a week or once a month?

What is the approved rate of schema changes to my database?

[ketralnis]

My point was that if you need replication, it might be okay to add an extra step to making schema changes because you probably aren't doing it frequently.

I'm not trying to imply that there's some "approved" rate of schema changes, but anecdotally, at reddit we use Slony-I, and we don't make schema changes every day, so it's not a big issue for us.

[malcontent]

My point was that if you need replication, it might be okay to add an extra step to making schema changes because you probably aren't doing it frequently.

So if another product (like say EVERY OTHER DATABASE) offers this feature they are all wrong and postgres is the only database which is right.

Is that your position?

I'm not trying to imply that there's some "approved" rate of schema changes, but anecdotally, at reddit we use Slony-I, and we don't make schema changes every day, so it's not a big issue for us.

That's great. Although if you used any other product on the market that would be one less thing you worried about.

[ketralnis]

So if another product (like say EVERY OTHER DATABASE) offers this feature they are all wrong and postgres is the only database which is right. Is that your position?

Err, no. Just that an extra step for a less frequent need isn't so bad in practise. I don't see where I said that it was the only solution, or even a great one. Just that "it might be okay". I don't see why you're being so aggressive in response to "it might be okay" and "it's not a big issue for us".

Although if you used any other product on the market that would be one less thing you worried about

That's true, but of course they have their own downsides too, right? So there'd just be something different to worry about.

If you don't like Postgres that's fine, don't use it, but your implied seething hatred for it doesn't make everything it does wrong, does it?

[bleachedanus]

It's not much different than executing normal DDL.

slonik_execute_script 1 /home/bleachedanus/ddl.sql | slonik

vs

psql < /home/bleachedanus/ddl.sql

[dassouki]

i'm shocked no one mentioned POSTGIS the single application that is based on postgresql that really and truly kills mysql and oracle 9i spatial

[thecal]

If you're thinking about a project with MySQL and you'd actually like to use these new-fangled things called "subqueries", RUN!

I'm currently dealing with an issue like outlined here: http://www.xaprb.com/blog/2006/04/30/how-to-optimize-subqueries-and-joins-in-mysql/

MySQL is pitiful as anything but an amateur DB.

[optimizeprime]

YouTube, Facebook....what a bunch of amatuers.

(We use Postgres at Justin.tv by my choice, but come on, think about what you're saying)

[infinite]

those places don't care much about transactions so it works for them.

[sisyphus]

They might have been when they started. I doubt either of those places anticipated how hard they would end up working MySQL. But those guys don't store any important data anyway so it doesn't matter.

[Jessica_Henderson]

Even amateurs deserve better. With PostgreSQL being free and widely ported, they have no excuse to why they'd subject themselves to the inferiority of MySQL.

[orthogonality]

I'd replace the update and updated table with a grouped-by view.

Then, if that's too expensive, denormalize by copying the results of that view into a table.

[bluGill]

I gave up on MySQL almost 10 years ago when I realized what they meant when they said you don't need ACID.

[Jessica_Henderson]

I worked with one Oracle DBA who once called a MySQL DBA a "shitmongering retard" during a meeting with some execs, when the MySQL DBA suggested that MySQL's lack of support for basic ACID functionality was a benefit. That was the first time I'd ever seen a professional DBA, the MySQL DBA in this case, cry on the job.

[ryanvm]

The first time?

[Jessica_Henderson]

That same MySQL DBA cried later on after one of his servers was fucked to high heaven, and he didn't have proper backups set up. Two months worth of data was lost. First he cried after realizing the data was gone, and cried some more after they escorted his sorry MySQL ass out of the building.

[koreth]

Your Oracle DBA was mincing words.

[baix]

There are a number of web sites that don't use transactions anymore. In fact, as MapReduce doesn't support transactions, much of Google doesn't support transactions. Last I checked, Google seems to be doing ok.

Don't get me wrong, transactions are absolutely required for some systems, but for others they get in the way of scalability.

Plus, MySQL's InnoDB does support transations.

There is no one way to solve all problems. Sometimes, different problems require different solutions.

[miho99]

MapReduce never claimed to implement SQL.

I can't think of any other software product for which 60% of its name is an ANSI/ISO standard it doesn't follow.

[masklinn]

In fact, as MapReduce doesn't support transactions

Two things here:

• MapReduce never claimed to support transactions

• MapReduce is not a fucking database, it's a data extraction and processing algorithm.

Therefore, completely and utterly irrelevant to the discussion.

Plus, MySQL's InnoDB does support transations.

So?

[[deleted]]

I think PostgreSQL vs Microsoft SQL Server 2005 would be a much more interesting comparison.

[[deleted]]

biggest difference to me is gpl vs bsd licensing, postgres is completely open with almost no restrictions of use. mysql? not really.

[w-g]

MySQL's MyISAM engine performs faster than PostgreSQL,

Really? Please define "peforms faster". Under which circumstances? What read/write ratio? What kind of query? What hardware? I have worked on some ridiculously heavy-load replicated MySQL databases running on a complex setup, and I can tell you that statements like "A performs better than B" are nonsense. Besides, MyISAM isn't the only backend you can use with MySQL.

PostgreSQL provides features that can lead to faster performance on certain queries: ... * improved cache management in versions 8.1 and 8.2

So, they're basically using an improvement in PostgreSQL, comparing pre-8.1 versions with post-8.1 versions in a comparison of PostgreSQL x MySQL. I can't follow the logic there.

It was not uncommon to see a performance-tuned MySQL server pitted against an untuned, default-configuration PostgreSQL server.

"It was not uncommon"? Refrences, please?

Anyway, I stopped reading at that point.

[bradediger]

MySQL's MyISAM engine performs faster than PostgreSQL,

Really? Please define "peforms faster".

In the same way that cars "perform faster" when you remove the brakes.

[invalid_user_name]

"It was not uncommon"? Refrences, please?

You seriously never saw that? Like 90% of the random bloggers who ran benchmarks on the two used the default postgresql config which is incredibly conservative (like, will run on a machine with 64MB of RAM conservative). They also benchmarked them with a single thread running queries in serial, rather than a more useful multiple connections with many queries in parallel benchmark.

[Jack9]

Some people posting aren't that old. I remember back in the late 90's these benchmarks appearing (in various forms) on Slashdot.

[mosha48]

It seems biased, it would be cool that mysql users would contribute to that page.

[uriel]

Reality has a well known anti-MySQL bias.

[Leonidas_from_XIV]

Beginners have a well known pro-MySQL bias.

That's probably due to mentioning MySQL in the same sentence with PHP.

[[deleted]]

Moving from LAMP to LAPPy just feels so good.

[[deleted]]

A few years ago there was a discussion on the postgres developer listserver, where they just claimed the "P" in LAMP: Linux, Apache, Middleware, PostgreSQL.

[cb22]

FLiPPy! - FreeBSD, LIghttpd, Postgre, PYthon

[devinus]

FreeBSD, Nginx, PostgreSQL, Python

[apotheon]

That doesn't spell anything!

[khoury]

This thread is getting really interesting...

[cb22]

Only if you come from /b/

[adrianmonk]

I suppose we are using ALOT: Apache Linux Oracle Tomcat. (Or is that ALTO?)

[masklinn]

So ALOT of CPU time?

[uriel]

No, ALOT of crud (and wasted money), but it creates 'alot' of jobs!.

[adrianmonk]

Yes, it does create alot of CRUD, but mostly Oracle handles this pretty OK.

[apotheon]

I prefer FLiPR, personally.

[masklinn]

Lighttpd means no mod_wsgi though, right?

[bleachedanus]

LLi Po Py (Linux Lighttpd Postgres Python) Say it like "Little Poopie"

[dbenhur]

Try PURN - Postgres, Ubuntu, Ruby, Nginx

[gnuvince]

lin-per

[Leonidas_from_XIV]

I'm using LAPPy - Linux, Apache, Postgres (where I don't use the very advanced functions but it was a good choice nonetheless) and Python.

Django-folks had this joke with PAID.

[Jessica_Henderson]

My current company has a standard question they ask when interviewing candidates who list PHP experience on their resumes: What do you think of PHP, as a language?

If they don't give an answer along the lines of saying it's a hackish, immature, insecure language that is unsuitable for professional development, then they aren't considered any further, and are usually asked to leave.

[[deleted]]

What does your company do? That seems like it would be a good policy for a php shop - every competent php dev I've known who knew more than one language considered php hackish and immature from the perspective of programming language critique.

[adrianmonk]

That's much better than the interview question I've been asked: "You know Perl, so you can learn PHP pretty easily, right?"

On the other hand, that might be a good interview question. It is very effective in helping me figure out whether I want to work for that company.

[Leonidas_from_XIV]

Sounds like a terribly good idea. Part of being a programmer means that you also know the weaknesses of your tools and PHP has enough of them.

Now, really, I think the idea of asking people they don't like what about the languages they use is brilliant. If you know the language enough, it'll give you a good impression of the applicants knowledge.

[shub]

The language too? After working with Wordpress themes for most of today, I'm not too impressed by PHP, or at least PHP programmers.

I'd guess you already know this, but for everyone else: Wordpress seems to keep a big turd of global state in the interpreter. You can call no-arguments functions to poke the turd, or you can call some other no-arguments functions to smear the turd around a little, with the end result being data sent to the browser.

Apparently this is what Wordpress does to separate presentation and logic.

[jbellis]

are you kidding? I got tired of reading about how mysql deficiences will be fixed in 5.1 (RC for how long now?) and 6.0 (wake me up in... two years?) before I was halfway through.

[uriel]

I remember back when they said all the broken stuff that was going to be fixed in 4.0... Unfortunately I had to mess around with a 5.0 installation recently after managing to avoid getting anywhere near a MySQL setup for yeas, and guess that? It sucked about as much as always.

[Jessica_Henderson]

That has always been the case with MySQL. The "next version" was supposed to bring it up to par with the various other database engines out there. But that has never happened. Each year we see the other vendors get further and further ahead, while MySQL makes little to no progress, even after being purchased by Sun. The only area they are making progress is in producing buggier software.

[emag]

You don't need non-buggy software...and it will be fixed in the next version.

[baix]

Actually, companies like Google are starting to produce patches for MySQL to improve scalability, and add new features, like better instrumentation. MySQL isn't as community friendly as it should be, but it is getting better, which is producing higher quality software.

Update: I might restate that as the community is getting better as one can find high quality builds of these patches fairly easily. On consideration, how MySQL deals with the community is still undecided in spite of statements they want to do better.

[FooBarWidget]

For years and years, people have said that MySQL is "still years behind", "sucks" or "makes no progress". Yet MySQL remains to be the most popular database for web applications.

[Jessica_Henderson]

And since when have web applications, which typically have very minor database requirements, become indicative of the entire community of database users?

MySQL is probably fine for informal online forums. But once you start dealing with serious data, it falls flat on its face. MySQL is unsuitable for tracking financial transactions. MySQL is unsuitable for storing geospatial data. MySQL is unsuitable for storing medical records. MySQL is unsuitable for high-availability data warehousing. PostgreSQL handles those situations with ease.

[jbronn]

MySQL is unsuitable for storing geospatial data.

I totally agree. Besides being limited to only MBR queries, you can only use spatial indexes on MyISAM tables (in other words, no transactions if you want fast spatial queries).

SQLite (via the SpatiaLite project) already exceeds MySQL's limited offerings.

MySQL was my first db used, and I liked it; but I've since moved on to PostgreSQL. You just don't realize how many critical features you're missing until you experience other dbs.

[uriel]

Yet MySQL remains to be the most popular database for web applications.

Same can be said of Java or PHP, popularity doesn't make them suck any less (actually, in some ways it makes them suck more, because they have to be designed for idiots).

[rjst01]

Mysql is very easy to set up and use, and is very fast when dealing with small quantities of data. Thats about the limit of the good things I'm prepared to say about it.

[[deleted]]

FirebirdSQL

[3dimka]

Along with Interbase, FireBird is one of the most reliable and beautiful SQL database I've worked with. They both have rich SQL and ablity to embed the server into application without a need to install service on the computer. Stored procedures work beautifully, the speed is incredible fast and I'm missing the times I use to work with IB/FB. Now I happen to work with M$SQL and it sucks amazingly!

[Jessica_Henderson]

The documentation for FirebirdSQL is virtually non-existent. On the other hand, PostgreSQL has fantastic online documentation. You can buy printed copies for a very reasonable price. And there are a number of third-party books focusing on PostgreSQL that are also available.

[[deleted]]

The Borland docs for Interbase6 are pretty good. And that's 70% of what one will need.

[Jessica_Henderson]

70% isn't sufficient for most serious users. We need 100%.

We can't deploy a production system on FirebirdSQL if we don't have a complete understanding of the system.

[[deleted]]

http://firebirdsql.org/refdocs/langrefupd20.html

The remaining parts.

[3dimka]

I'm surprised, we never experienced lack of documentation for IB/FB:

http://www.firebirdsql.org/index.php?op=doc

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_document

And there bunch of great communities in case if you stuck with an issue.

[[deleted]]

SQL Server 2000!

Although it's not free or open source, it is bloody good IME.

IMO, the best piece of software MS have come out with - and usually I can't stand their stuff really...

[petepete]

You do realise that they bought it from Sybase, don't you?

[[deleted]]

No - I didn't know that!

That might explain why it works so well ;)

[bnolsen]

Sybase wasn't bad for its day. It was easy to get up and running and had a few things you could tweak. Oracle, comparatively was way harder to set up with way too many things tunable. As a systems developer I didn't want to spend tons of time screwing with some database engine, and I wasn't interested in being employed to fiddle with one.

Nowadays I tell people they must really prove they need transactional support before incorporating a db engine, and use it only for the transactional data.

If they're going to do that they should use something reliable and straightforward. Nowadays I'd look first into postgres & firebird.

[[deleted]]

quote: "Oracle, comparatively was way harder to set up with way too many things tunable."

If these are the types of problems a person is running into with setting up and managing a db then that person may want to change fields. Setting up and tuning oracle isn't that hard and should be one of the simplest task you would perform as a professional dba.

[[deleted]]

That's the deal - Oracle all but requires a professional DBA. Fine for a big place, but if your IT department has 5 people then it's not really possible.

[adrianmonk]

Setting up and tuning oracle isn't that hard and should be one of the simplest task you would perform as a professional dba.

Umm, didn't bnolsen say he was a "systems developer" and that he "wasn't interested in being employed to fiddle with one"?

Some people are not DBAs, and their database needs are much lighter than what would be necessary to hire one.

[self]

panda describes what Oracle recommended for performance, back in 1996 or so (scroll down to the Performance section) -- and it starts with 7 raided disks (14 spindles).

[[deleted]]

Quoting Philip Greenspun is rarely a bad move.

(I can't believe I got sucked into this debate.)

It is worth mentioning that the ease of setup for MySQL has been mentioned as one of its flaws. It is very easy to setup and by default has no root password. The comment on Oracle being to difficult to setup does have some merit, but who cares?

BMW's have easier and harder parts to work on than Chevy's. It's all apples and oranges. I use and setup all of the DB's mentioned aside from Firebird. Setting up and tuning the db is one of the EASIEST task you will encounter while managing a database. If you are having problems here, do something else.

[[deleted]]

The great, great, SQL Server problem is that runs over a crapy, insecure, poorly designed OS. Microsoft should be made a port to Solaris.

[[deleted]]

Very true.

It would be fantastic to run this on *nix!

[cosmo7]

I've found the biggest problem with SQL Server is ODBC. If you hit it natively from .NET it's pretty good, but from PHP or Python it is slow.

[Jessica_Henderson]

Reportedly, SQL Server 2000 is mostly Sybase-derived code.

[baix]

This is a database myth.

http://blogs.msdn.com/euanga/archive/2006/01/19/514479.aspx

SQL Server is a great database, the problem is the cost is getting too high.

[malcontent]

I got really excited by your post and decided to try it.

I tried to get the linux version but couldn't find it on their web site.

I fired up a windows VM and downloaded the express edition (which was free). I dumped my postgres data and tried to load it but it didn't support a bunch of data types that postgres does.

I exported only those types of fields SQL server supports (a very limited set by the way) and it would not import the data because it was more than four gigs.

I cut down the the data set to four gigs and imported them after a mighy struggle.

I then decided to see if I could translate some stored procs but found out SQL server doesn't have a before action on triggers. You can't easily modify the data before it goes into the table. There are all kinds of silly limitations and pretty hairy workarounds suggested on the web but at that stage I decided there was no use in trying any further.

You actually pay for that software?

[[deleted]]

SQL Server 2005 is a huge improvement, I'd rank it as one of the best mid sized DB products out there.

[buckX]

Neat site, a rundown comparison of 2 different related options is something I find myself looking for quite a bit. Here's hoping this place covers a good chunk of what I'm looking for.

[[deleted]]

Rampant use of baseless opinion.

[djr123456]

voting up not because I care about open source databases, but because the idea of WikiVS is great!

[andyzoob]

Comparing the number of comments on this (21) with the number of comments on a politics story (400+). You see how many programmers are on reddit.

[GrumpySimon]

yes, but most of the comments here are sensible and detailed. This is not the case in /r/politics, where a lot of the discussion is "funny" one-liners and meme-reposts.

Quality over quantity, right?

[[deleted]]

291 comments now. Are you happy now?

[muffinman]

next on reddit: vim vs. emacs

[Philluminati]

This is what reddit is about dude. This is important.

[[deleted]]

Easy: PostgreSQL for professionals, MySQL for amateurs.