8 ms·

MySQL (and thus MariaDB I presume) and SQLite seem to be pretty poor in supporting these "new" features. SQLite seems logical because it needs to be kept lean

• weaksauce 12y ago
  Oracle influence? Postgres is the leader now in mindshare and features for the opensource offerings. If you like MySQL you could check out mariadb
• barrkel 12y ago
  My experience with PostgreSQL and MySQL is that PostgreSQL supports lots of features, but performance needs a very careful eye - often a neat feature isn't as useful as it seems because optimization isn't good enough. Whereas MySQL tends to be very good at what it can do, and makes it easy to do silly things, like turn off referential integrity in a slow query to boost performance. It almost feels like a worse-is-better story. As a programmer, PostgreSQL is much better to work with; more tools, better EXPLAIN, more features, more types, more of almost everything. But to use in the heat of battle, it's less clear-cut. PostgreSQL's replication story is complicated. MySQL master-master replication is fairly easy to set up, and if you use a master as a hot failover, it all mostly just works; when the primary site comes back up, it resyncs with the failover. PostgreSQL has a lot of different replication stories - without a strong central narrative, it's hard to gain confidence.
  • noehp 12y ago
    This doesn't match my experience at all. MySQL performance is highly variable, and it's incredibly easy to write simple queries that have truly abysmal performance. Postgres on the other hand, has always tended towards making things work well (a step that mysql often skips), and then work quickly thereafter. A lot of MySQL acolytes say Postgres is slow because, unlike MySQL, it doesn't ship with unsafe defaults. MySQL doesn't just allow you to do dumb things, it starts off with many of those settings as the defaults. To me, the real problem is that people likebarrkel exist. He doesn't know what he's on about, but he likes MySQL. Most of wheat he wrote is flatly false, but he said it confidently. And he's employed someplace that probably uses MySQL. MySQL got adoption for two reasons: 1) it used to be easier to install; and 2) it has unsafe defaults that mean if an idiot runs a benchmark, it wins. That's it. That's how it won market. After that, it was network effects, and nothing else. MySQL is a turd. It requires substantial expertise to use MySQL because it is such an awful and dangerous tool. It slows you down as you get better. But most of the people who use it don't know any better, or (like barrkel) they spew nonsense that is the opposite of reality. So it wins. Network effects suck.
    • laurencerowe 12y ago
      MySQL also had much cheaper connection setup costs which was a big deal for the CGI and PHP crowds who setup the world at the beginning of every request.
      • 72deluxe 12y ago
        This is very true. If they used something like pgpool-ii it'd be fine. But that would require more effort for the server administrators.
    • threeseed 12y ago
      A simpler and faster product won ? I am truly shocked. And the issues around "safety" stopped being a concern for most developers a decade ago when the ORM was invented. So this idea that you need "substantial expertise" to use it is simply ridiculous.
    • ecopoesis 12y ago
      I would also say MySQL was adopted by lots of people because for a long time it had a better replication story then Postgres. Easy to setup replication was a pretty killer feature, even if it didn't always quite work as expected.
      • empthought 12y ago
        I think "easier replication" and "unsafe defaults" kind of go hand in hand...
    • Gigablah 12y ago
      Speaking as someone who made the switch from MySQL to Postgres... I'm just happy that I can now trust subqueries and schema updates to not blow up my database. And I don't know how I got by without lateral joins and hstore.
    • barrkel 12y ago
      He doesn't know what he's on about, but he likes MySQL. You're putting words in my mouth that I didn't say. I don't like MySQL. I prefer PostgreSQL. And I have had a few rough times optimizing some queries in PostgreSQL, whereas I've had fewer such bad times with MySQL, despite using it more often. It's anecdata. Take it for what it's worth. Time sinks in MySQL have come more from its crappy defaults, from its bizarre error handling (or lack thereof) in bulk imports, and most recently, a regression caused by a null pointer in the warning routine. If I were working on my own project, I'd probably go with PostgreSQL and figure out the replication story. But I'm not. I do use PostrgeSQL on my personal projects. (If there was one feature I'd add to PostgreSQL, it would be some means of temporarily and selectively disabling referential integrity. Not deferring it, not removing and readding foreign keys, just disabling. The app I work on does regular 10k-1M+ row bulk inserts, usually into a new table every time (10s of thousands of tables), but sometimes appending to an already 100M+ row table. It would be nice to have referential integrity outside of the bulk inserts, but not pay the cost on bulk insert.)
  • moe 12y ago
    it all mostly just works Yes, that sums up MySQL pretty well. And then one day, one of your masters segfaults for no discernible reason. And when you restart it, the replication process (or even the InnoDB recovery) fails to resume with a generic error message that you can't find any useful information about in the mess that MySQL calls "documentation". That's when you realise that "it all mostly just works" is really not what you want from your database.
  • ako 12y ago
    I did some tests with Postgres recently to test query optimization. Was pretty impressed, especially where it applied the correct index on an inline view (2nd example): * http://mxblog.eu/link/post/sql-is-about-what-data-you-want-not-how-to-get-it http://mxblog.eu/link/post/sql-is-about-what-data-you-want-n... * http://mxblog.eu/link/post/impact-of-inline-views-on-query-plan http://mxblog.eu/link/post/impact-of-inline-views-on-query-p...
  • lgunsch 12y ago
    I've never been with a company that didn't have serious problems with MySQL replication. At least once a month master-master replication breaks horribly and must be manually fixed; often by having to delete and remove data. MySQL replication half-works at best.
    • barrkel 12y ago
      I look forward to the day that happens at my work then :) To be clear, our master/master replication is strictly read-only at one site and read-write at the other site, and never read-write simultaneously. We have yet to see issues in production under fairly hefty write load, and we've failed over numerous times, and back again. But it's only been 10 months or so.
• threeseed 12y ago
  > but do people know why MySQL is lagging behind so much Because for 99% of the MySQL user base there isn't a need for these features. Those using MySQL at scale are using them as dumb key-value stores with horizontally sharding. Those who aren't typically are using them with an ORM and so they aren't dealing with the database at the SQL layer. Everyone else who is manually writing SQL generally was on or moved to Oracle, Teradata, SQL Server, PostgreSQL etc anyway.
  • tkyjonathan 12y ago
    This whole statement is 99% wrong
• jeffdavis 12y ago
  It seems to be a philosophical difference. A lot of people seem to think that the database should only support primitive operations, and the rest should be left to application code. I am not one of those people -- I think a good database system (like postgres) can make many things dramatically simpler.
  • gaius 12y ago
    In the 90s the MySQL guys believed that transactions and referential integrity, should be done in the application...
    • ddorian43 12y ago
      Maybe you need just key-value access and the rest to be in the app, maybe you need just file access and the rest in app, maybe you need just hd-block-access and the rest in app etc