12 ms·

MySQL - Do Not Pass This Way Again

224 points by craigkerstiens 14y ago

exabrial 14y ago
>>It's good enough. No it ain't. There are plenty of other equally-capable data storage systems that don't come with MySQL's huge raft of edge cases and quirks. Actually, it is good enough. Good enough to powere billions of websites. Good enough not to pay for Oracle, DB2, or trying to cram some half-finished nosql mess in where a relational database works better. MySQL isn't an end all, but please, don't pretend that NoSQL holds all the answers.
- zzzeek 14y ago
  what's wrong with this picture? Oracle/DB2/SQL Server/$$$ <------------ (?) ------------- MySQL --------> NoSQL someone's missing the elephant in the room.
  - robfig 14y ago
    Which elephant is in your room?
- andrewaylett 14y ago
  I imagine that the author had in mind other Free relational systems, rather than NoSQL or proprietary. For example, off the top of my head: * Postgres * Apache Derby * SQLite All of which I'd prefer to using MySQL in just about any context, and each of which has contexts for which it's overwhelmingly the best choice.
dangrossman 14y ago
I appreciate this well-argued piece of persuasive writing for not choosing MySQL, but the premise is surprising -- I don't recall seeing, on Hacker News or elsewhere, any writeups from companies that chose MySQL then ran into significant problems they had to architect around, nor writeups from companies that chose MySQL then had to rip everything out to switch to something in the same family of solutions (Postgres, Oracle, etc).
- simonw 14y ago
  We migrated Lanyrd from MySQL to PostgreSQL, primarily to reduce the pain involved in running schemes alterations against large tables but we've since been enjoying some if the more advanced PostgreSQL features (pg_trgm indexes for example). You can read about our migration here: http://lanyrd.com/blog/2012/lanyrds-big-move/ http://lanyrd.com/blog/2012/lanyrds-big-move/
  - taligent 14y ago
    Just wanted to confirm something. You say you have no single point of failure but you are running everything in one data center ?
    - simonw 14y ago
      That was slightly loose wording in the article: yes, the single data center is currently a single point of failure (though we can spin up a replacement stack elsewhere very quickly). Andrew was referring to the way we had rearranged our software stack to reduce the SPOFs (our previous architecture had a single load balancer for example).
    - twerquie 14y ago
      There is always a single point of failure if you zoom out far enough.
  - mscarborough 14y ago
    Thanks for being clear and detailed about your DB migration. I've been involved in a few and they've generally been brought on by DBAs convincing the bosses that "everything is wrong"...once it was done the DBAs wanted to blame the developers again.
- jes5199 14y ago
  I worked at a large startup that was trying to migrate from MySQL to Postgres because of how long table migrations take on MySQL. There's a tendency for adding a column in MySQL to a table to be stop-the-world for the whole server, and it can take hours. They had some pretty serious workarounds for that, and some of them were "try to never change the database structure". There was some thought that there were other problems that Postgres would solve, some advocacy happened here: http://corner.squareup.com/2011/06/postgresql-data-is-important.html http://corner.squareup.com/2011/06/postgresql-data-is-import...
deleted 14y ago
[deleted]
wereHamster 14y ago
If you must use MySQL, at least switch to MariaDB. Those Oracle folks can not be trusted anymore, not even with a toaster.
- fatbird 14y ago
  But you can trust the fork started by the guy who sold it to Sun in the first place, then followed it to Oracle, then led the exodus from Oracle to capitalize on anti-Oracle feeling by starting a fork? Riiiiiiiiiight....
  - taligent 14y ago
    Then there is always the Percona or Twitter or millions of other forks around.
    - jacques_chester 14y ago
      Percona Server is good. The ability to monitor is great and the supporting tools are very helpful.
- AaronBBrown 14y ago
  I agree that the MariaDB and Percona Server versions of MySQL are far superior in many ways, but Oracle, with 5.6 has proved their commitment to MySQL with some awesome new features. I admit there has been a reduction in transparency with the test cases fiasco, but beyond FUD, what is it that they "can't be trusted with?" Are you concerned that they are in there secretly making a bittorrent out of your database or something?
matt2000 14y ago
I'd be very interested to hear from people using other databases on whether their DB of choice is much better. I've been using MySQL for a while, have been burned by a few things, but figured it was mainly my fault. If indeed there are better options I'd love to hear the details. (Just to be clear, I know about other databases, just aren't sure if any are that much better in real world use).
- saurik 14y ago
  Many of the complaints I hear people make about the entire concept of an "RDBMS" (often then to motivate why the NoSQL solution they decided to start using is better) are actually MySQL-specific issues that do not affect PostgreSQL (or Oracle, or usually SQL Server; I only mention PostgreSQL, as you wanted a concrete experience); one key example is "if you want to change your schema, it requires locking the entire system and rewriting the table" <- no, as the schema is just metadata; you should be able to do these things under first-class transactions, and PostgreSQL supports this just fine.
  - rosser 14y ago
    To be fair, there are cases where schema changes in PostgreSQL require re-writing the table, too. Like, for example, when you change the data type of an existing column. Otherwise, you're good, though.
    - kconor 14y ago
      To be fair, if you want to change the datatype of data in a NoSQL system, you have to rewrite it as well.
    - saurik 14y ago
      Yes, but that case comes up less often and isn't what I see NoSQL people complaining about ;P. (Also, when I've listed that as an explicit caveat recently, I often get corrected that they changed the ramifications of that recently, and it only sometimes has to happen, so I figured I'd just explicitly list the situations where you clearly should never have needed to rewrite the table.) Generally, though, this is related to be able to do table changes under transaction locks: I have often enjoyed being able to, under an atomic transaction, replace a table with a view over that table, or make modifications to indexes and columns that I then rollback if there's a mistake.
danso 14y ago
Ugh, maybe my Internet is slow, but I can't seem to get the page to load. Maybe there should be an unofficial rule that if you're going to write a worthwhile article about database and, I assume since I can't yet read it, performance, you should enable caching on your blog Edit: here's the raw text version stored on github https://raw.github.com/ojacobson/grimoiredotca/master/wiki/mysql/choose-something-else.md https://raw.github.com/ojacobson/grimoiredotca/master/wiki/m...
- eksith 14y ago
  They can't expect the page to be on HN in the first place. Though, I agree, caching couldn't hurt. Loaded for me just now, albeit after 30 seconds.
redegg 14y ago
This looks similar to the MongoDB FUD from a year or two ago. Nevertheless, I don't like MySQL and prefer PostgreSQL for all my projects.
- thanasisp 14y ago
  That's a detailedand well documented article sir. Nothing like FUD.
  - jack9 14y ago
    Using a documented interface and claiming it's inherently unsafe... try{System.out.println(5/0);}catch(ArithmeticException ae){} NOTHING HAPPENS OMG. Exactly like FUD.
16s 14y ago
MySQL is the visual basic of SQL databases. Anyone can set one up and use it. The problem is that many non-technical people use MySQL and then think they know all about DBs. Ask them what ACID is, or about foreign key constraints. You'll get blank stares. If you know what those things are and value them, you probably don't use MySQL.
- AaronBBrown 14y ago
  Can you provide some citations to this claim? I know a lot of people who understand ACID, Foreign Keys, and have experience with other DBs (like PostgreSQL) and still often choose MySQL based on its merits.
  - jiggy2011 14y ago
    I think he is talking about "people who use mysql only because it was the easiest thing to learn" don't know these things, not "experienced DBAs/devs who happen to be using MySQL".
    - spudlyo 14y ago
      Yeah, he's not talking about DBAs who work at Facebook, Yahoo, YouTube, Wikipedia or Twitter. Just because half the Alexa top 10 uses MySQL in production doesn't mean it's not just used by non-technical noobs who don't know any better.
- taligent 14y ago
  I really don't know where to begin with such a stupid comment. How about you start with listing which of these companies needs educating: http://www.mysql.com/customers/ http://www.mysql.com/customers/ Facebook ? Twitter ? Amazon ? Flickr ?
  - jacques_chester 14y ago
    In some of these cases MySQL is not being used as an RDBMS. And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database. Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y"). I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 billion transactions per day (and that was 5 years ago). Does UPS make DB2 better or worse than MySQL? Answer: it's irrelevant. DB2 and MySQL would need to be picked on their merits, not their users.
contingencies 14y ago
Used MySQL for 10+ years. I found it great for most purposes. I don't feel I left MySQL because of MySQL's failings, but that of all monolithic RDBMS.
- jacques_chester 14y ago
  Have you tried other RDBMSes?
  - contingencies 14y ago
    OK I'll bite: Yes. Ultimately my problem with the old monolithic RDBMS is architectural. Q: "How do you get 24x7x365 service on a mission-critical system that depends on a huge monolithic RDBMS datastore, preserving the capacity for RDBMS major-version software upgrades (protocol, on-disk format, etc.) and no downtime even between major versions?" A: "While you could umm and ahh about it for awhile, basically, you don't. It's too big. Decentralization, plan-to-fail, clustering ('private cloud', hah), and commodity hardware are your friends. Embrace them and enjoy lower blood pressure." If you don't have high availability requirements, RDBMS can still be a great and simple solution. Right tool for the job. (I have simply personally drifted from RDBMS as the requirements of systems I tend to work on has grown. My current rule of thumb is roughly: 'Make all storage backends service-provider abstracted (swappable, easy to benchmark, unit test, etc.). When choosing a backend for a storage implementation - if you can't SQLite it, don't SQL it.')
    - jacques_chester 14y ago
      Any central service is going to be a point of failure. This isn't unique to RBMSes (the other classic SPOF is message buses). The idea that RDBMSes are unsuitable for HA applications is ... well to be charitable, I'll call it "inaccurate". Most of the techniques that are used for HA were first invented for conventional databases and/or their best friends, mainframes and midrange systems. I agree however that it is a question of picking the right tool for the job. I'm a data-safety bigot. I require a great deal of talking down from my tree. These days I can understand that, yes, OK, a consistent and durable model of Facebook comments probably isn't really that important. But I will bet folding money that Facebook stores their financial data in a huge monolithic RDBMS datastore, like Amazon, Microsoft, Google and Apple do.
viraptor 14y ago
I'm really not sure what to think of that article. On one hand side, I definitely agree with it and I've experienced many issues with MySQL. On the other, there are so many... strange points, it's hard for me to trust the author about the parts that are new to me. Things I've found weird so far are: - "my favourite example being a fat-fingered UPDATE query where a mistyped = (as -, off by a single key) caused 90% of the rows in the table to be affected," - if I ever run "rm -rf . /" fat-fingering the space, I'm going to blame myself only - not fileutils or bash - this has nothing to do with the database - (about backups) "Unless you meticulously lock tables or make the database read-only for the duration," - this is not trivial, but logging onto slave and doing "FLUSH TABLES WITH READ LOCK, sync, snapshot, UNLOCK TABLES" is not rocket science either. And it's well documented on their "backup methods" page. - "It's unrealistic to expect every single user to run SHOW CREATE TABLE before every single query, or to memorize the types of every column in your schema, though." - ... yeah... we shouldn't ask them to remember the syntax either - just keep guessing until you get everything right ;) - "Foreign keys are ignored if you spell them certain, common, ways" - another case of "I want to use the wrong syntax, but still get the right answer" I really wish he limited himself to hard facts - the main idea of the article wouldn't suffer at all. There are enough things to hate in MySQL without going into the subjective and "inconvenient, but still ok" parts.
- rosser 14y ago
  "Foreign keys are ignored if you spell them certain, common, ways" - another case of "I want to use the wrong syntax, but still get the right answer" Both forms of declaring foreign keys are SQL-standard compliant syntax. That MySQL silently ignores the "inline" version is the "wrong" here, not the syntax. From MySQL's own docs: "Furthermore, InnoDB does not recognize or support “inline REFERENCES specifications” (as defined in the SQL standard) where the references are defined as part of the column specification. InnoDB accepts REFERENCES clauses only when specified as part of a separate FOREIGN KEY specification. For other storage engines, MySQL Server parses and ignores foreign key specifications." [1] [1] http://dev.mysql.com/doc/refman/5.5/en/create-table.html http://dev.mysql.com/doc/refman/5.5/en/create-table.html
  - 14y ago
apapli 14y ago
I originally was using MySQL to learn with rails because it was so simple to set up on my Mac. The only reason I migrated (quite early I may add) is that at the time Heroku pretty much mandated I move to postgres. I'm glad I made the move, but I'd say awareness of the alternatives is the limiting factor. The brand awareness MySQL has is pretty big compared with many others. I wonder how much impact Heroku's decision to support postgres has helped those similar to myself drop mysql.
marcofloriano 14y ago
Php and Mysql sucks ... yeah for sure, but that´s how i get the job done each and every day.
ybrs 14y ago
i read until the backup process and gave up reading through, for cold backups of online databases, you should use percona's extrabackup, its open source and free and works perfectly. http://www.percona.com/doc/percona-xtrabackup/ http://www.percona.com/doc/percona-xtrabackup/ if you are using mysql a simple googling "hot backup mysql" will lead to that, i guess author didn't even bother to search. besides, you need to use replication and connect a couple of slaves if you care about being online and backup from one of the slaves - which is a common practice for all databases not for mysql. if you are trying to dump from the master without slaves good luck with any database.
- zorlem 14y ago
  XtraBackup has its limitations wrt to locking when you've got a mix between InnoDB and MyISAM tables. The problem with taking a backup from a MySQL slave is that the data is not guaranteed to be identical to the master, thanks to the subtle problems and peculiarities of the MySQL master-slave replication (some of them are described in the OP). For precisely this reason I install an automated job that periodically checksums the tables and sends the results to the DBA role.
zzzeek 14y ago
this is my favorite MySQL "decision", that the GROUP BY keyword by default (that is, unless you turn it off with the late-added magic flag ONLY_FULL_GROUP_BY) will gladly select an essentially "random" (well, the first row based on INSERT order, which in SQL is as good as random) row for you: mysql: create table data (token_a varchar(10), token_b varchar(10)); Query OK, 0 rows affected (0.05 sec) mysql: insert into data (token_a, token_b) values ('A', 'A'); Query OK, 1 row affected (0.01 sec) mysql: insert into data (token_a, token_b) values ('A', 'B'); Query OK, 1 row affected (0.00 sec) mysql: insert into data (token_a, token_b) values ('B', 'B'); Query OK, 1 row affected (0.00 sec) mysql: insert into data (token_a, token_b) values ('B', 'A'); Query OK, 1 row affected (0.00 sec) mysql: select * from data group by token_a; +---------+---------+ | token_a | token_b | +---------+---------+ | A | A | | B | B | +---------+---------+ 2 rows in set (0.00 sec) Note here the value we get for "token_b" is based on whether or not "A" or "B" were inserted first. The second "token_b" for each "token_a" (as well as any number of other rows that might follow it for that "token_a") is just discarded. The scary thing is that I semi-regularly come across applications in Very Important Industries that have large amounts of SQL that rely upon this behavior of "picking any old row" for you, rather than selecting a MAX() or MIN() of some column and then joining to a subquery of the GROUP BY + aggregate....because joining to a subquery in MySQL also performs like crap.
- taligent 14y ago
  You say ONLY_FULL_GROUP_BY was late added. But there are posts talking about this setting in 2002.
  - zzzeek 14y ago
    but only added in version 5 (I was using it back with version 3 in the late 90s): http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#sqlmode_only_full_group_by http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#... > Do not permit queries for which the select list or (as of MySQL 5.0.23) HAVING list refers to nonaggregated columns that are not named in the GROUP BY clause.
jacques_chester 14y ago
This is a great article. But I really wish it had sources for each of the claims. I would be interested to read the relevant documentation, because some of these directly describe problems I've had with running a Wordpress installation. And I've been blaming Wordpress for it. There's possibly a big mea culpa brewing; but I'd really like to look at the specifics.
- lucb1e 14y ago
  Oh just blame Wordpress. My self-written software has no performance issues on MySQL, but Wordpress loading times are over two seconds with a default installation.
  - jacques_chester 14y ago
    > Oh just blame Wordpress. I usually do. But in this case it looks as though MySQL's underwhelming query planner might be at fault.
    - toast0 14y ago
      MySQL's query planner is actually pretty good, but there are some things that are just not going to be fast; most of which is documented, almost all of which can be seen with describe select ...; if it uses a temporary table, it's probably necessary, and it's definitely going to be slow once you have enough rows. If WordPress uses any of these things, it's not MySQL's fault.
      - elliptic 14y ago
        Its query planner may be good (I don't know about this), in the sense that it can typically choose the best of a bad lot. However, the query executor (of stock MySQL) is awful - no hash joins? No merge joins? It is good compared to what?
      - sergiosgc 14y ago
        This may have been true ten years ago. Not anymore. Mysql query planner is dumb as a rock. Easy example: instead of referring to a table in FROM, try using a sub query with SELECT * from the same table. It's an easy reproduction of the planner failing to process the query tree. It should result in the same execution tree. It results in a temporary table being created, as an identical copy of the original table. Before you attack the query itself, and note that it is an example.
mscarborough 14y ago
This person doesn't even offer a solution? How is it that people who have blogs that take 30 seconds to load continue to give performance advice that gets upvoted? The funny thing is that this blog's performance is based on some cookie. If I reload in Chrome? 2 sec. If I reload in "Incognito Chrome", it's again really slow. So seriously, just stop with these authoritative blog posts when you don't even know what you're talking about.
- fdr 14y ago
  When criticizing a piece of software as popular as MySQL, offering a solution is an exercise in futility: it only leads people to think that the author is wrong because the alternative posited is wrong for them. See the endless MySQL vs. PostgreSQL discussions (which are not entirely without merit: the two system do have overlap in targeted users). Instead, this author his simply focused on numerous detailed aspects of MySQL that he/she seems to think would be seen by most people as particularly insane, without need for comparison. I think there's a place for that.
  - mscarborough 14y ago
    You're right, offering a solution to MySQL problems in a thread is generally useless. I don't really get what point the author is trying to make. I also don't take detailed performance advice from people who can't keep a blog up. Yeah, must be the wrong backend.
    - willlll 14y ago
      How could you possibly not get the point? It's the first two (2) sentences "Considering MySQL? Use something else."
      - mscarborough 14y ago
        I use MySQL and Postgres, depending on the project. What other option is so obvious that you can't even name it?
nnnnni 14y ago
"I'm going to rant against MySQL, but I'm not going to suggest a better alternative."
- dvnlgls 14y ago
  a similar discussion appears above.
- twerquie 14y ago
  "Not MySQL" is good advice. Look into alternatives, there are many good ones.
- jmix 14y ago
  In what entitled universe do you live in where a guy who carefully and patiently points out problems is also obligated to solve every single one of them? Also, do you really need someone to spell out the alternatives to MySQL? There are too many to list.
  - nnnnni 14y ago
    The article would have been much more credible if it would have said something like "try postgresql instead". It has nothing to do with entitlements.
    - jmix 14y ago
      He does not need to be able to point to an extant, better alternative for his criticisms to be "credible." BTW, I can't believe you're implying that his post is not credible. The practical outcome of your demand for a solution is to shut down legitimate criticism.
pippy 14y ago
I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great feature. It's also about twice as slow as MySQL (admittedly this is likely due to the maturity of the environment I'm working in). I personally like PostgreSQL. However I see it more as a guilty nerd pleasure rather than a development time effective solution. MSSQL is very nice, and my experience has been the best. Microsoft's tools are top quality. You'll find yourself very productive; creating advanced SQL views, mirroring, and snapshots. However MSSQL reeks of vender lockin, I had to virtualise the MSSQL tools, and getting the drivers to work on Linux took almsot two days of googling. Despite ease of use, the vendor lockin doesn't make MSSQL worth it.
- deleted 14y ago
  [deleted]
- sadmysqluser 14y ago
  If you would rather have faulty data than none when something's wrong with your application, then MySQL is your DB of choice.
  - jeffdavis 14y ago
    I disagree that MySQL is a better choice when you have "faulty" data: * In postgres, you have PL/python (or PL/V8JS, or perl, or many other languages) to help you through the mess. For instance, you could write a canonicalization function to help you put the data into a more-queryable form. You can then even index on that function. * Powerful triggers might help with post-processing, or putting data into some queue of "bad data" that needs to be cleaned up later. Maybe by doing so, you realize that the data isn't "bad", your schema just needs to be updated to reflect new interesting cases. * You can pull data in from remote sources with foreign data wrappers, which might be necessary to clean the data up properly (e.g. one extra join against the company LDAP directory using the email might be able to canonicalize those employee names). * You can catch errors using subtransactions and have a different processing path for data that doesn't fit in the schema. Maybe some of these features exist in MySQL (I haven't been a real user since around 2003, aside from a bit of administration). But in postgres, these features all work together seamlessly along with all of the other features in postgres to make it all work nicely and without a pile of caveats. And that matters a lot when trying to wrangle strange data.
hpaavola 14y ago
Instead of writing these rants go and build a WAMP like package with PostgreSQL or other alternatives. That might actually do some good.
- zorlem 14y ago
  > Instead of writing these rants go and build a WAMP like package with PostgreSQL or other alternatives. That might actually do some good. You mean like WAPP, the package installer provided by BitNami [1]? I don't see a problem with a well-argumented rant, IMO it's quite helpful as it sparks such discussions, let people improve their knowledge and make better informed decissions, and, not the least important, forces a vendor to work towards improving their software. [1] http://bitnami.org/stack/wapp http://bitnami.org/stack/wapp
sadmysqluser 14y ago
Ronald Bradford's http://www.slideshare.net/ronaldbradford/my-sql-idiosyncrasies-that-bite-otn http://www.slideshare.net/ronaldbradford/my-sql-idiosyncrasi... is worth reviewing for anyone who runs MySQL. I especially like how he explains SQL_MODE bit by bit and ends up recommending SQL_MODE = ALLOW_INVALID_DATES, ANSI_QUOTES, ERROR_FOR_DIVISION_ZERO, HIGH_NOT_PRECEDENCE,IGNORE_SPACE,NO_AUTO_CREATE_USER, NO_AUTO_VALUE_ON_ZERO, NO_BACKSLASH_ESCAPES, NO_DIR_IN_CREATE, NO_ENGINE_SUBSTITUTION, NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS, NO_UNSIGNED_SUBTRACTION,NO_ZERO_DATE, NO_ZERO_IN_DATE, ONLY_FULL_GROUP_BY, PAD_CHAR_TO_FULL_LENGTH (5.1.20), PIPES_AS_CONCAT, REAL_AS_FLOAT, STRICT_ALL_TABLES, STRICT_TRANS_TABLES I also recommend "MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation" http://blog.mozilla.org/it/2013/01/17/mysql-5-1-vs-mysql-5-5-floats-doubles-and-scientific-notation/ http://blog.mozilla.org/it/2013/01/17/mysql-5-1-vs-mysql-5-5... for anyone who working with non-integer numerics.
Happymrdave 14y ago
I worked at one data-heavy startup where things were on MySQL and even with a lot of consulting by Percona, eventually it just couldn't keep up with our needs, and the project was ported to PostgreSQL. I've worked on other projects that were less data intensive and MySQL worked fine though. If given a choice, I'll take PostgreSQL any day, but I do understand that people are hesitant to change database whey they don't need to. If you are encountering trouble though, by all means, move on.
dendory 14y ago
I started 7 years ago with SQLite and still have all my sites and webapps running on that. Works wonderfully for me. Meanwhile I must have seen close to a dozen data storage systems become popular then be replaced by the next big thing, from MySQL to NoSQL and everything in between.
- brazzy 14y ago
  MySQL became popular rather more than7 years ago, and still is.
- TazeTSchnitzel 14y ago
  I love SQLite. It's simple, it doesn't make a fuss, and it does what you'd expect. And better yet, since it's a single file application database instead of a database running on a server, support for it is built in to Python, and you using it is as simple as an import statement and .connect() - no server to configure.
paul_f 14y ago
There is a bit of an elitist attitude in this point of view. Of course MySQL is not perfect. That's a strawman argument, nobody is claiming it is. For 99+% of all applications that need a simple database, it is more than "good enough".
billrobertson42 14y ago
The article lost me at this. > Already on MySQL? Migrate. Got a silly little thing in the corner running just fine on MySQL. Go spend time on it? No.

224 points by craigkerstiens 14y ago

>>It's good enough. No it ain't. There are plenty of other equally-capable data storage systems that don't come with MySQL's huge raft of edge cases and quirks. Actually, it is good enough. Good enough to powere billions of websites. Good enough not to pay for Oracle, DB2, or trying to cram some half-finished nosql mess in where a relational database works better. MySQL isn't an end all, but please, don't pretend that NoSQL holds all the answers.

zzzeek 14y ago
what's wrong with this picture? Oracle/DB2/SQL Server/$$$ <------------ (?) ------------- MySQL --------> NoSQL someone's missing the elephant in the room.
- robfig 14y ago
  Which elephant is in your room?
andrewaylett 14y ago
I imagine that the author had in mind other Free relational systems, rather than NoSQL or proprietary. For example, off the top of my head: * Postgres * Apache Derby * SQLite All of which I'd prefer to using MySQL in just about any context, and each of which has contexts for which it's overwhelmingly the best choice.

dangrossman 14y ago

I appreciate this well-argued piece of persuasive writing for not choosing MySQL, but the premise is surprising -- I don't recall seeing, on Hacker News or elsewhere, any writeups from companies that chose MySQL then ran into significant problems they had to architect around, nor writeups from companies that chose MySQL then had to rip everything out to switch to something in the same family of solutions (Postgres, Oracle, etc).

simonw 14y ago
We migrated Lanyrd from MySQL to PostgreSQL, primarily to reduce the pain involved in running schemes alterations against large tables but we've since been enjoying some if the more advanced PostgreSQL features (pg_trgm indexes for example). You can read about our migration here: http://lanyrd.com/blog/2012/lanyrds-big-move/ http://lanyrd.com/blog/2012/lanyrds-big-move/
- taligent 14y ago
  Just wanted to confirm something. You say you have no single point of failure but you are running everything in one data center ?
  - simonw 14y ago
    That was slightly loose wording in the article: yes, the single data center is currently a single point of failure (though we can spin up a replacement stack elsewhere very quickly). Andrew was referring to the way we had rearranged our software stack to reduce the SPOFs (our previous architecture had a single load balancer for example).
  - twerquie 14y ago
    There is always a single point of failure if you zoom out far enough.
- mscarborough 14y ago
  Thanks for being clear and detailed about your DB migration. I've been involved in a few and they've generally been brought on by DBAs convincing the bosses that "everything is wrong"...once it was done the DBAs wanted to blame the developers again.
jes5199 14y ago
I worked at a large startup that was trying to migrate from MySQL to Postgres because of how long table migrations take on MySQL. There's a tendency for adding a column in MySQL to a table to be stop-the-world for the whole server, and it can take hours. They had some pretty serious workarounds for that, and some of them were "try to never change the database structure". There was some thought that there were other problems that Postgres would solve, some advocacy happened here: http://corner.squareup.com/2011/06/postgresql-data-is-important.html http://corner.squareup.com/2011/06/postgresql-data-is-import...

deleted 14y ago

[deleted]

wereHamster 14y ago

If you must use MySQL, at least switch to MariaDB. Those Oracle folks can not be trusted anymore, not even with a toaster.

fatbird 14y ago
But you can trust the fork started by the guy who sold it to Sun in the first place, then followed it to Oracle, then led the exodus from Oracle to capitalize on anti-Oracle feeling by starting a fork? Riiiiiiiiiight....
- taligent 14y ago
  Then there is always the Percona or Twitter or millions of other forks around.
  - jacques_chester 14y ago
    Percona Server is good. The ability to monitor is great and the supporting tools are very helpful.
AaronBBrown 14y ago
I agree that the MariaDB and Percona Server versions of MySQL are far superior in many ways, but Oracle, with 5.6 has proved their commitment to MySQL with some awesome new features. I admit there has been a reduction in transparency with the test cases fiasco, but beyond FUD, what is it that they "can't be trusted with?" Are you concerned that they are in there secretly making a bittorrent out of your database or something?

matt2000 14y ago

I'd be very interested to hear from people using other databases on whether their DB of choice is much better. I've been using MySQL for a while, have been burned by a few things, but figured it was mainly my fault. If indeed there are better options I'd love to hear the details. (Just to be clear, I know about other databases, just aren't sure if any are that much better in real world use).

saurik 14y ago
Many of the complaints I hear people make about the entire concept of an "RDBMS" (often then to motivate why the NoSQL solution they decided to start using is better) are actually MySQL-specific issues that do not affect PostgreSQL (or Oracle, or usually SQL Server; I only mention PostgreSQL, as you wanted a concrete experience); one key example is "if you want to change your schema, it requires locking the entire system and rewriting the table" <- no, as the schema is just metadata; you should be able to do these things under first-class transactions, and PostgreSQL supports this just fine.
- rosser 14y ago
  To be fair, there are cases where schema changes in PostgreSQL require re-writing the table, too. Like, for example, when you change the data type of an existing column. Otherwise, you're good, though.
  - kconor 14y ago
    To be fair, if you want to change the datatype of data in a NoSQL system, you have to rewrite it as well.
  - saurik 14y ago
    Yes, but that case comes up less often and isn't what I see NoSQL people complaining about ;P. (Also, when I've listed that as an explicit caveat recently, I often get corrected that they changed the ramifications of that recently, and it only sometimes has to happen, so I figured I'd just explicitly list the situations where you clearly should never have needed to rewrite the table.) Generally, though, this is related to be able to do table changes under transaction locks: I have often enjoyed being able to, under an atomic transaction, replace a table with a view over that table, or make modifications to indexes and columns that I then rollback if there's a mistake.

danso 14y ago

Ugh, maybe my Internet is slow, but I can't seem to get the page to load. Maybe there should be an unofficial rule that if you're going to write a worthwhile article about database and, I assume since I can't yet read it, performance, you should enable caching on your blog Edit: here's the raw text version stored on github https://raw.github.com/ojacobson/grimoiredotca/master/wiki/mysql/choose-something-else.md https://raw.github.com/ojacobson/grimoiredotca/master/wiki/m...

eksith 14y ago
They can't expect the page to be on HN in the first place. Though, I agree, caching couldn't hurt. Loaded for me just now, albeit after 30 seconds.

redegg 14y ago

This looks similar to the MongoDB FUD from a year or two ago. Nevertheless, I don't like MySQL and prefer PostgreSQL for all my projects.

thanasisp 14y ago
That's a detailedand well documented article sir. Nothing like FUD.
- jack9 14y ago
  Using a documented interface and claiming it's inherently unsafe... try{System.out.println(5/0);}catch(ArithmeticException ae){} NOTHING HAPPENS OMG. Exactly like FUD.

16s 14y ago

MySQL is the visual basic of SQL databases. Anyone can set one up and use it. The problem is that many non-technical people use MySQL and then think they know all about DBs. Ask them what ACID is, or about foreign key constraints. You'll get blank stares. If you know what those things are and value them, you probably don't use MySQL.

AaronBBrown 14y ago
Can you provide some citations to this claim? I know a lot of people who understand ACID, Foreign Keys, and have experience with other DBs (like PostgreSQL) and still often choose MySQL based on its merits.
- jiggy2011 14y ago
  I think he is talking about "people who use mysql only because it was the easiest thing to learn" don't know these things, not "experienced DBAs/devs who happen to be using MySQL".
  - spudlyo 14y ago
    Yeah, he's not talking about DBAs who work at Facebook, Yahoo, YouTube, Wikipedia or Twitter. Just because half the Alexa top 10 uses MySQL in production doesn't mean it's not just used by non-technical noobs who don't know any better.
taligent 14y ago
I really don't know where to begin with such a stupid comment. How about you start with listing which of these companies needs educating: http://www.mysql.com/customers/ http://www.mysql.com/customers/ Facebook ? Twitter ? Amazon ? Flickr ?
- jacques_chester 14y ago
  In some of these cases MySQL is not being used as an RDBMS. And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database. Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y"). I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 billion transactions per day (and that was 5 years ago). Does UPS make DB2 better or worse than MySQL? Answer: it's irrelevant. DB2 and MySQL would need to be picked on their merits, not their users.

contingencies 14y ago

Used MySQL for 10+ years. I found it great for most purposes. I don't feel I left MySQL because of MySQL's failings, but that of all monolithic RDBMS.

jacques_chester 14y ago
Have you tried other RDBMSes?
- contingencies 14y ago
  OK I'll bite: Yes. Ultimately my problem with the old monolithic RDBMS is architectural. Q: "How do you get 24x7x365 service on a mission-critical system that depends on a huge monolithic RDBMS datastore, preserving the capacity for RDBMS major-version software upgrades (protocol, on-disk format, etc.) and no downtime even between major versions?" A: "While you could umm and ahh about it for awhile, basically, you don't. It's too big. Decentralization, plan-to-fail, clustering ('private cloud', hah), and commodity hardware are your friends. Embrace them and enjoy lower blood pressure." If you don't have high availability requirements, RDBMS can still be a great and simple solution. Right tool for the job. (I have simply personally drifted from RDBMS as the requirements of systems I tend to work on has grown. My current rule of thumb is roughly: 'Make all storage backends service-provider abstracted (swappable, easy to benchmark, unit test, etc.). When choosing a backend for a storage implementation - if you can't SQLite it, don't SQL it.')
  - jacques_chester 14y ago
    Any central service is going to be a point of failure. This isn't unique to RBMSes (the other classic SPOF is message buses). The idea that RDBMSes are unsuitable for HA applications is ... well to be charitable, I'll call it "inaccurate". Most of the techniques that are used for HA were first invented for conventional databases and/or their best friends, mainframes and midrange systems. I agree however that it is a question of picking the right tool for the job. I'm a data-safety bigot. I require a great deal of talking down from my tree. These days I can understand that, yes, OK, a consistent and durable model of Facebook comments probably isn't really that important. But I will bet folding money that Facebook stores their financial data in a huge monolithic RDBMS datastore, like Amazon, Microsoft, Google and Apple do.

viraptor 14y ago

I'm really not sure what to think of that article. On one hand side, I definitely agree with it and I've experienced many issues with MySQL. On the other, there are so many... strange points, it's hard for me to trust the author about the parts that are new to me. Things I've found weird so far are: - "my favourite example being a fat-fingered UPDATE query where a mistyped = (as -, off by a single key) caused 90% of the rows in the table to be affected," - if I ever run "rm -rf . /" fat-fingering the space, I'm going to blame myself only - not fileutils or bash - this has nothing to do with the database - (about backups) "Unless you meticulously lock tables or make the database read-only for the duration," - this is not trivial, but logging onto slave and doing "FLUSH TABLES WITH READ LOCK, sync, snapshot, UNLOCK TABLES" is not rocket science either. And it's well documented on their "backup methods" page. - "It's unrealistic to expect every single user to run SHOW CREATE TABLE before every single query, or to memorize the types of every column in your schema, though." - ... yeah... we shouldn't ask them to remember the syntax either - just keep guessing until you get everything right ;) - "Foreign keys are ignored if you spell them certain, common, ways" - another case of "I want to use the wrong syntax, but still get the right answer" I really wish he limited himself to hard facts - the main idea of the article wouldn't suffer at all. There are enough things to hate in MySQL without going into the subjective and "inconvenient, but still ok" parts.

rosser 14y ago
"Foreign keys are ignored if you spell them certain, common, ways" - another case of "I want to use the wrong syntax, but still get the right answer" Both forms of declaring foreign keys are SQL-standard compliant syntax. That MySQL silently ignores the "inline" version is the "wrong" here, not the syntax. From MySQL's own docs: "Furthermore, InnoDB does not recognize or support “inline REFERENCES specifications” (as defined in the SQL standard) where the references are defined as part of the column specification. InnoDB accepts REFERENCES clauses only when specified as part of a separate FOREIGN KEY specification. For other storage engines, MySQL Server parses and ignores foreign key specifications." [1] [1] http://dev.mysql.com/doc/refman/5.5/en/create-table.html http://dev.mysql.com/doc/refman/5.5/en/create-table.html
- 14y ago

apapli 14y ago

I originally was using MySQL to learn with rails because it was so simple to set up on my Mac. The only reason I migrated (quite early I may add) is that at the time Heroku pretty much mandated I move to postgres. I'm glad I made the move, but I'd say awareness of the alternatives is the limiting factor. The brand awareness MySQL has is pretty big compared with many others. I wonder how much impact Heroku's decision to support postgres has helped those similar to myself drop mysql.

marcofloriano 14y ago

Php and Mysql sucks ... yeah for sure, but that´s how i get the job done each and every day.

ybrs 14y ago

i read until the backup process and gave up reading through, for cold backups of online databases, you should use percona's extrabackup, its open source and free and works perfectly. http://www.percona.com/doc/percona-xtrabackup/ http://www.percona.com/doc/percona-xtrabackup/ if you are using mysql a simple googling "hot backup mysql" will lead to that, i guess author didn't even bother to search. besides, you need to use replication and connect a couple of slaves if you care about being online and backup from one of the slaves - which is a common practice for all databases not for mysql. if you are trying to dump from the master without slaves good luck with any database.

zorlem 14y ago
XtraBackup has its limitations wrt to locking when you've got a mix between InnoDB and MyISAM tables. The problem with taking a backup from a MySQL slave is that the data is not guaranteed to be identical to the master, thanks to the subtle problems and peculiarities of the MySQL master-slave replication (some of them are described in the OP). For precisely this reason I install an automated job that periodically checksums the tables and sends the results to the DBA role.

zzzeek 14y ago

this is my favorite MySQL "decision", that the GROUP BY keyword by default (that is, unless you turn it off with the late-added magic flag ONLY_FULL_GROUP_BY) will gladly select an essentially "random" (well, the first row based on INSERT order, which in SQL is as good as random) row for you: mysql: create table data (token_a varchar(10), token_b varchar(10)); Query OK, 0 rows affected (0.05 sec) mysql: insert into data (token_a, token_b) values ('A', 'A'); Query OK, 1 row affected (0.01 sec) mysql: insert into data (token_a, token_b) values ('A', 'B'); Query OK, 1 row affected (0.00 sec) mysql: insert into data (token_a, token_b) values ('B', 'B'); Query OK, 1 row affected (0.00 sec) mysql: insert into data (token_a, token_b) values ('B', 'A'); Query OK, 1 row affected (0.00 sec) mysql: select * from data group by token_a; +---------+---------+ | token_a | token_b | +---------+---------+ | A | A | | B | B | +---------+---------+ 2 rows in set (0.00 sec) Note here the value we get for "token_b" is based on whether or not "A" or "B" were inserted first. The second "token_b" for each "token_a" (as well as any number of other rows that might follow it for that "token_a") is just discarded. The scary thing is that I semi-regularly come across applications in Very Important Industries that have large amounts of SQL that rely upon this behavior of "picking any old row" for you, rather than selecting a MAX() or MIN() of some column and then joining to a subquery of the GROUP BY + aggregate....because joining to a subquery in MySQL also performs like crap.

taligent 14y ago
You say ONLY_FULL_GROUP_BY was late added. But there are posts talking about this setting in 2002.
- zzzeek 14y ago
  but only added in version 5 (I was using it back with version 3 in the late 90s): http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#sqlmode_only_full_group_by http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#... > Do not permit queries for which the select list or (as of MySQL 5.0.23) HAVING list refers to nonaggregated columns that are not named in the GROUP BY clause.

jacques_chester 14y ago

This is a great article. But I really wish it had sources for each of the claims. I would be interested to read the relevant documentation, because some of these directly describe problems I've had with running a Wordpress installation. And I've been blaming Wordpress for it. There's possibly a big mea culpa brewing; but I'd really like to look at the specifics.

lucb1e 14y ago
Oh just blame Wordpress. My self-written software has no performance issues on MySQL, but Wordpress loading times are over two seconds with a default installation.
- jacques_chester 14y ago
  > Oh just blame Wordpress. I usually do. But in this case it looks as though MySQL's underwhelming query planner might be at fault.
  - toast0 14y ago
    MySQL's query planner is actually pretty good, but there are some things that are just not going to be fast; most of which is documented, almost all of which can be seen with describe select ...; if it uses a temporary table, it's probably necessary, and it's definitely going to be slow once you have enough rows. If WordPress uses any of these things, it's not MySQL's fault.
    - elliptic 14y ago
      Its query planner may be good (I don't know about this), in the sense that it can typically choose the best of a bad lot. However, the query executor (of stock MySQL) is awful - no hash joins? No merge joins? It is good compared to what?
    - sergiosgc 14y ago
      This may have been true ten years ago. Not anymore. Mysql query planner is dumb as a rock. Easy example: instead of referring to a table in FROM, try using a sub query with SELECT * from the same table. It's an easy reproduction of the planner failing to process the query tree. It should result in the same execution tree. It results in a temporary table being created, as an identical copy of the original table. Before you attack the query itself, and note that it is an example.

mscarborough 14y ago

This person doesn't even offer a solution? How is it that people who have blogs that take 30 seconds to load continue to give performance advice that gets upvoted? The funny thing is that this blog's performance is based on some cookie. If I reload in Chrome? 2 sec. If I reload in "Incognito Chrome", it's again really slow. So seriously, just stop with these authoritative blog posts when you don't even know what you're talking about.

fdr 14y ago
When criticizing a piece of software as popular as MySQL, offering a solution is an exercise in futility: it only leads people to think that the author is wrong because the alternative posited is wrong for them. See the endless MySQL vs. PostgreSQL discussions (which are not entirely without merit: the two system do have overlap in targeted users). Instead, this author his simply focused on numerous detailed aspects of MySQL that he/she seems to think would be seen by most people as particularly insane, without need for comparison. I think there's a place for that.
- mscarborough 14y ago
  You're right, offering a solution to MySQL problems in a thread is generally useless. I don't really get what point the author is trying to make. I also don't take detailed performance advice from people who can't keep a blog up. Yeah, must be the wrong backend.
  - willlll 14y ago
    How could you possibly not get the point? It's the first two (2) sentences "Considering MySQL? Use something else."
    - mscarborough 14y ago
      I use MySQL and Postgres, depending on the project. What other option is so obvious that you can't even name it?

nnnnni 14y ago

"I'm going to rant against MySQL, but I'm not going to suggest a better alternative."

dvnlgls 14y ago
a similar discussion appears above.
twerquie 14y ago
"Not MySQL" is good advice. Look into alternatives, there are many good ones.
jmix 14y ago
In what entitled universe do you live in where a guy who carefully and patiently points out problems is also obligated to solve every single one of them? Also, do you really need someone to spell out the alternatives to MySQL? There are too many to list.
- nnnnni 14y ago
  The article would have been much more credible if it would have said something like "try postgresql instead". It has nothing to do with entitlements.
  - jmix 14y ago
    He does not need to be able to point to an extant, better alternative for his criticisms to be "credible." BTW, I can't believe you're implying that his post is not credible. The practical outcome of your demand for a solution is to shut down legitimate criticism.

pippy 14y ago

I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great feature. It's also about twice as slow as MySQL (admittedly this is likely due to the maturity of the environment I'm working in). I personally like PostgreSQL. However I see it more as a guilty nerd pleasure rather than a development time effective solution. MSSQL is very nice, and my experience has been the best. Microsoft's tools are top quality. You'll find yourself very productive; creating advanced SQL views, mirroring, and snapshots. However MSSQL reeks of vender lockin, I had to virtualise the MSSQL tools, and getting the drivers to work on Linux took almsot two days of googling. Despite ease of use, the vendor lockin doesn't make MSSQL worth it.

deleted 14y ago
[deleted]
sadmysqluser 14y ago
If you would rather have faulty data than none when something's wrong with your application, then MySQL is your DB of choice.
- jeffdavis 14y ago
  I disagree that MySQL is a better choice when you have "faulty" data: * In postgres, you have PL/python (or PL/V8JS, or perl, or many other languages) to help you through the mess. For instance, you could write a canonicalization function to help you put the data into a more-queryable form. You can then even index on that function. * Powerful triggers might help with post-processing, or putting data into some queue of "bad data" that needs to be cleaned up later. Maybe by doing so, you realize that the data isn't "bad", your schema just needs to be updated to reflect new interesting cases. * You can pull data in from remote sources with foreign data wrappers, which might be necessary to clean the data up properly (e.g. one extra join against the company LDAP directory using the email might be able to canonicalize those employee names). * You can catch errors using subtransactions and have a different processing path for data that doesn't fit in the schema. Maybe some of these features exist in MySQL (I haven't been a real user since around 2003, aside from a bit of administration). But in postgres, these features all work together seamlessly along with all of the other features in postgres to make it all work nicely and without a pile of caveats. And that matters a lot when trying to wrangle strange data.

hpaavola 14y ago

Instead of writing these rants go and build a WAMP like package with PostgreSQL or other alternatives. That might actually do some good.

zorlem 14y ago
> Instead of writing these rants go and build a WAMP like package with PostgreSQL or other alternatives. That might actually do some good. You mean like WAPP, the package installer provided by BitNami [1]? I don't see a problem with a well-argumented rant, IMO it's quite helpful as it sparks such discussions, let people improve their knowledge and make better informed decissions, and, not the least important, forces a vendor to work towards improving their software. [1] http://bitnami.org/stack/wapp http://bitnami.org/stack/wapp

sadmysqluser 14y ago

Ronald Bradford's http://www.slideshare.net/ronaldbradford/my-sql-idiosyncrasies-that-bite-otn http://www.slideshare.net/ronaldbradford/my-sql-idiosyncrasi... is worth reviewing for anyone who runs MySQL. I especially like how he explains SQL_MODE bit by bit and ends up recommending SQL_MODE = ALLOW_INVALID_DATES, ANSI_QUOTES, ERROR_FOR_DIVISION_ZERO, HIGH_NOT_PRECEDENCE,IGNORE_SPACE,NO_AUTO_CREATE_USER, NO_AUTO_VALUE_ON_ZERO, NO_BACKSLASH_ESCAPES, NO_DIR_IN_CREATE, NO_ENGINE_SUBSTITUTION, NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS, NO_UNSIGNED_SUBTRACTION,NO_ZERO_DATE, NO_ZERO_IN_DATE, ONLY_FULL_GROUP_BY, PAD_CHAR_TO_FULL_LENGTH (5.1.20), PIPES_AS_CONCAT, REAL_AS_FLOAT, STRICT_ALL_TABLES, STRICT_TRANS_TABLES I also recommend "MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation" http://blog.mozilla.org/it/2013/01/17/mysql-5-1-vs-mysql-5-5-floats-doubles-and-scientific-notation/ http://blog.mozilla.org/it/2013/01/17/mysql-5-1-vs-mysql-5-5... for anyone who working with non-integer numerics.

Happymrdave 14y ago

I worked at one data-heavy startup where things were on MySQL and even with a lot of consulting by Percona, eventually it just couldn't keep up with our needs, and the project was ported to PostgreSQL. I've worked on other projects that were less data intensive and MySQL worked fine though. If given a choice, I'll take PostgreSQL any day, but I do understand that people are hesitant to change database whey they don't need to. If you are encountering trouble though, by all means, move on.

dendory 14y ago

I started 7 years ago with SQLite and still have all my sites and webapps running on that. Works wonderfully for me. Meanwhile I must have seen close to a dozen data storage systems become popular then be replaced by the next big thing, from MySQL to NoSQL and everything in between.

brazzy 14y ago
MySQL became popular rather more than7 years ago, and still is.
TazeTSchnitzel 14y ago
I love SQLite. It's simple, it doesn't make a fuss, and it does what you'd expect. And better yet, since it's a single file application database instead of a database running on a server, support for it is built in to Python, and you using it is as simple as an import statement and .connect() - no server to configure.

paul_f 14y ago

There is a bit of an elitist attitude in this point of view. Of course MySQL is not perfect. That's a strawman argument, nobody is claiming it is. For 99+% of all applications that need a simple database, it is more than "good enough".

billrobertson42 14y ago

The article lost me at this. > Already on MySQL? Migrate. Got a silly little thing in the corner running just fine on MySQL. Go spend time on it? No.