MySQL 8.0 is now generally available | Hacker News Reader

MySQL 8.0 is now generally available

mysqlserverteam.com

221 pointstheodorejb100 comments

I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not:

  create table fib ( a integer, b integer );
  insert into fib (a, b) values (1, 0);
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  select a, b from fib;

The correct result according to the SQL standard is a == 8 and b == 5. In MySQL the result is a == 16 and b == 16. They do document this in the manual, saying UPDATE evaluates the assignments left to write, and note that this deviates from the standard.

MariaDB is the same prior to 10.3.5. Starting with 10.3.5 it defaults to left to write evaluation, but you can set the SIMULTANEOUS_ASSIGNMENT mode flag to make UPDATE evaluate the assignments simultaneously instead of left to right.

I believe that all other common SQL databases (Sqlite, PostgreSQL, Oracle, Microsoft SQL Server) follow the standard.

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

I agree. If it's desired, use a config setting to make it the default. It was already standard practice in any MySQL database I rolled out to set InnoDB as the default storage engine in the config until it became the shipped default. Like transaction isolation levels, this is something you either set as an administrator for your need, or you let the application setup guide steer you, or you let the application queries specifically set it, if the application needs it. Otherwise,you risk causing real data corruption and loss to existing customers purely for the benefit of being more compliant in your default configuration.

A global and per-session setting is sufficient and more beneficial, IMO, so I think MariaDB took the right approach. If MySQL still doesn't have that setting, well, that's troubling, but I can't say I'm entirely surprised.

MariaDB and MySQL have different goals here - MariaDB wants to offer drop-in compatibility for Oracle. MySQL has a core-audience of OLTP apps, that are mostly developed for it specifically.

When designing features, I think it's important to make sure they can benefit the highest number of users possible. For this one, I don't think it can ever be the default because of the burden of backward compatibility. So it is difficult to justify developing it.

Hi! Former MySQL Product Manager here. I'm not sure I ever looked at this issue specifically, but you are correct: the burden of breaking backwards compatibility should be high, and supported by major use cases.

To give a similar example, that I did look at: MySQL can enable more standards equivalent identifier quoting (via an SQL mode): https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmod...

To enable that by default would break a lot of applications.

I don't see the problem here. Make the default preserve backward compatibility, but offer an option like 'SIMULTANEOUS_ASSIGNMENT' to be standards-compliant.

Simpler example:

https://bugs.mysql.com/bug.php?id=13943

Reported over 12 years ago...

I think it's disappointing that MySQL is developed in private and then only pushed to GitHub when released.

I had noticed that it had not been updated in 3 months:

MySQL in the Cloud Native Interactive Landscape https://landscape.cncf.io/grouping=landscape&landscape=datab...

Diff showing last commit https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3...

At least it's released at all, but yeah, not a community collab :|

One of the most interesting new features to me is full support of MySQL 8.0 as a JSON based document store using the new DevAPI[1].

There is a separate blog post highlighting it: https://mysqlserverteam.com/mysql-8-0-announcing-ga-of-the-m...

1. https://dev.mysql.com/doc/x-devapi-userguide/en/devapi-users...

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago.

Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

No, at this point Maria has surpassed MySQL, however over time we'll likely see the two diverge as MySQL creates new storage types and heads in a different strategic direction.

The big features that MySQL has been lacking, MariaDB has had since at least 10.2 (Apr 2016) or earlier. Specifically I'm talking about Windowing functions, CTEs, JSON support, GIS support, Metadata in transactions (DDL statements).

At this point MySQL is playing catch-up to MariaDB.

Former MySQL Product Manager here (no longer affiliated). To cover your specifics:

MySQL was first in offering JSON with 5.7. It is still well ahead, for example, there is no JSON_TABLE, aggregate functions, native type or partial update in MariaDB. Some examples of the value here: https://mysqlserverteam.com/mysql-8-0-from-sql-tables-to-jso...

Both have always had GIS support, but have taken it in a different direction. With MySQL, the GIS is now based on Boost.Geometry and has Geography support.

w.r.t. metadata in transactions - I am not sure which feature you refer to here. The native innodb-based dictionary is a MySQL only feature.

For Window functions and CTEs, they were added at a similar time, but MySQL is on a ~3yr release cycle. MariaDB is on a ~1yr.

> I am not sure which feature you refer to here

The same complaint that every single person brings up about MySQL when being compared to Postgres, including in this thread: DDL changes made during transactions cannot be rolled back.

MariaDB does not have that feature: https://mariadb.atlassian.net/browse/MDEV-4259

Mariadb has JSON it just doesn't call it that - it's terminology is dynamic columns.

Source: have code that works on both.

It has both (now). It's a stretch to say Dynamic columns are on the same level. For example, could you index them with virtual generated columns? The syntax is also not as transparent to applications as the ->> JSON operator.

Oracle owns the JavaScript trademark and has started enforcing it. Kinda wise in hindsight that Mariadb didn't call it json?

I think Mariadb was there first. I think the format is very similar at the bit level, but the MySQL has nicer API with automatic returning it as text to apps rather than exposing the bits. I dislike json_extract and wish >> worked but it doesn't seem to on my percona server :(

Anyhow, you'll look back when you've got more distance from Oracle and realize that you don't need to try and convince yourself that MySQL was better quite so hard ;)

JSON is part of the SQL 2016 standard and exists in other databases as well. I don't see how the trademark is relevant here.

I wish we could be more civil and not resort to petty insults. Is there anything I wrote you can dispute with a source?

There s a difference: MySQL has specific a datatype for JSON aside from only having JSON-related functions working n strings, which has a few benefits:

* The JSON datatype guarantees the content is valid JSON

* access to fields can be faster even without dynamic/virtual columns

* since 8.0 there are special optimizations for doing partial updates, which means that not the full JSON data has to be rewritten on small changes https://mysqlserverteam.com/partial-update-of-json-values/

The main reason I don't use mariaDb is the non support of nullable spatial index.

https://mariadb.com/kb/en/library/spatial-index/

I feel the same way. I've been using and tracking both since the mid to late 90s.

I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities.

In the meantime PostgreSQL gets better at the same pace.

I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL

I am a solid Postgres guy, but MySQL still has a better multi-master replication story. Confident that Postgres will eventually surpass it, possibly even in a later iteration of 10.

Now in a world where Postgres exists why would anyone use MongoDB is a valid question...

Postgres 11? Postgres 10 will only get bug fixes.

The version numbering was changed with 10

1. LAMP - If you're working with shared hosting, there isn't much of a choice.

2. WordPress.

3. If you need something simple and basic, MySQL is much easier to get up and running.

I agree with 1 and 2 but I don't understand 3. Can you please elaborate?

Biggest difference for me is that MySQL always pushed a simpler user structure while most *nix Postgres packages prefer having corresponding native OS users by default (PAM vs password auth). Also, it always seemed easier to migrate/upgrade MySQL data folders compared to Postgres ones. The specifics aren’t coming to mind right now, though. Finally I know way too many folks who prefer phpMyAdmin, especially when provided from their cheap shared hosting provider.

Don’t get me wrong, I prefer Postgres generally too, but I can definitely see wins to MySQL on ease-of-use. Especially the less standard but more forgiving SQL syntax and simple DESCRIBE commands. Yes the quirks add up for MySQL but Postgres has its share of quirks too.

I'm not a DBA, and it could very well be that it's because I'm coming from the LAMP world, but when I need something light and simple, MySQL or MariaDB fit the bill a lot more than Postgres.

In MySQL there are five steps: Install MySQL (creating root user at the same time), CREATE DATABASE X, USE DATABASE X, CREATE table Y, work.

If I need something more secure, I'll add a "Create User"/add permissions step in there.

For some reason, step 2-4 (create user and set up database/table) give me a headache in Postgres.

Sounds like Postgres could use some initiative to make the experience easier/faster for beginners and new deployments (if popularity is something valuable for them). That's what many people value in MySQL apart from the familiarity.

I rarely come across tutorials for beginners where MySQL isn't treated like the only option, even if only by omission. I wouldn't be surprised if students only found out about the viability of different databases after a few years.

Install Postgres;

`su postgres` or whatever user it uses;

run `psql`;

`CREATE USER X IDENTIFIED BY PASSWORD;`

`CREATE DATABASE X OWNER X;'

Now X can connect there and add tables as he wishes.

Postgres onboarding coule be better, but it is naive to choose a tool you will use for years based on the first 5 minutes experience.

CREATE USER X IDENTIFIED BY PASSWORD

Googled that and not one result on the first page mentioned PostgreSQL. I don't think this approach is a common one at all. More to the point, I'm not sure i've ever seen that set of instructions anywhere, ever, for pgsql. Every tutorial and intro focuses on running 'createuser'.

Oh, yeah, and you'll need to be root to go in and futz with your pg_hba.conf file, then have permissions to write it out and restart the server (probably as root).

This 'createuser' approach hasn't been a '5 minute experience' - it's been the approach that is promoted as the default answer/approach almost everywhere I've ever looked for several years.

    \help CREATE USER

    \help CREATE DATABASE

Initial setup of users and permissions in MySQL is vastly simpler that in Postgres, IMO. It may seem like they are close, but in a world where pg_hba.conf ships with a config that easily confuses those that are unaware of Postgres's ident verification, you'll have people get frustrated often, and in a non-easy to diagnose way (at least for people at a familiarity level where they'll run into this).

MySQL is still a perfectly reasonable choice for massive-scale OLTP workloads. In my mind, a few things MySQL excels at:

* Threaded connection model. Postgres still uses process-per-conn right? This is very painful in situations with high connection churn / fire-and-forget db conns, which are required in some circumstances (heavily sharded environments where keeping persistent connection pools between all app servers and db servers is not practical)

* Ecosystem and experienced talent pool. Among companies with the largest database fleets, a plurality (maybe even a majority) use MySQL, or at least started out on MySQL. This translates to a greater availability of engineers worldwide with experience using and automating giant sharded MySQL fleets, more exposure to MySQL's edge cases, more familiarity with very specific performance characteristics and tuning, etc.

* MySQL's pluggable storage engine API allows flexibility for interesting future possibilities. Facebook migrated part of their MySQL fleet's storage engine from InnoDB (btree-based) to MyRocks (LSM-based) and achieved incredible compression benefits as a result, which translates to huge cost savings, while still being much easier than moving to another DBMS altogether. And AFAIK Postgres does not have comparable compression levels to MyRocks at this time.

* Replication options. I'm sure Postgres will catch up here, but its logical replication support is still relatively new, whereas MySQL has always used logical replication and supports a lot of different topologies and configurations. (Although, I won't cite master-master support as many folks do... it is not a good setup in MySQL and has long been discouraged in the community.)

* InnoDB's use of a clustered index for primary key means that it performs better than a non-clustered storage solution for some (many?) workloads.

Don't get me wrong, Postgres is a wonderful database and absolutely has many qualities and features that MySQL lacks. But it's not the black-and-white situation that some make it out to be.

And don't forget the TokuDB storage engine. It has some very interesting and different scaling/performance characteristics which can provide dramatic improvements for some workloads.

(Even though TokuDB is probably not the "best" choice for my workload, I love it for my text-heavy tables because its performance is still great and its on-disk compression ratios are superb.)

Fair enough, but personally I would be very hesitant to adopt TokuDB for a new use-case in 2018. Its rate of development and adoption have both slowed considerably in recent years, and MyRocks covers similar use-cases.

This covers probably the most important reasons to use MySQL over PostgreSQL:

https://eng.uber.com/mysql-migration/

The TL;DR is that PostgreSQL on-disk storage format leads to much higher IOPs for the same workload. For companies running OLTP at scale, the cost differences can be huge.

I've been to a few talks from the PostgreSQL lead developers where they mention this.

Their opinion was mostly "Uber could have just asked us the right way to do it" and "We believe Uber's new engineering leader needed something to do"

I've had count(*) queries take like literally days in Postgres. Want to insert a lot of data? Expect it to cost a lot of RAM. It's got high features but some really rough edges too :|

the same would happen in MySQL right? select count(*) does a table scan

count(*) doesn't do full table scan as it's not tied to specific data. It has special handling logic. The only case where it might have to do a full table scan is if you try to count() on a specific (nullable?) column without an index.

I've always had select count(*) do a full table scan (or at least take considerable time) in innodb... Did something change?

Without a WHERE clause, select count(*) still does a full table scan (or full index scan) in InnoDB, and probably always will.

It is optimized in MyISAM via table-level metadata, which is only possible because MyISAM doesn't use MVCC or support transactions.

In InnoDB, you can get an estimated row count from SHOW TABLE STATUS, but the estimate is based on table stats and can be wildly inaccurate.

Depends on the storage engine afair, but both innodb an myisam have either index or global metadata based solution for this. I think in myisam its an estimste if you use count(*) so you need to use count(id) to get an exact value. This is all well documented

> why, in a world where PostgreSQL exists, would anyone use MySQL.

You could also ask why would anyone use Postgres? Either question is equally absurd. If MySQL and its forks work well enough for Google, Facebook, Uber, AirBNB, Alibaba and Linkedin, why should anyone take it on face value that Postgres is an unambiguously better choice?

That said I've toyed with switching in the past. Ten years ago, the MySQL query optimiser was fairly junk and I wanted to switch for that alone.[1] The main thing that held me back was that my application has hundreds—quite probably thousands—of SQL queries coded into it.

Despite "SQL" being a notional standard, even the most basic queries would need to be extensively reformatted to be compatible with Postgres. The effort required to rewrite all of these queries simply can't be justified, particularly because we simply don't have any problems with MariaDB. The query optimiser is a lot better now, such that I now rarely encounter situations where a sensible query doesn't yield an efficient execution plan.

[1] Between 2000 and 2007 I had spent a lot of time with MSSQL for a different project and I had grown to appreciate its excellent query optimiser and execution plan visualiser. Ten years on and I still haven't seen any F/OSS solution that does as good a job as SQL Server 2000 in this regard. The most recent version I've used is 2005 so it might be even better today. And believe me, I was not a fan of Microsoft in the 2000s.

regarding query plan visualizer, workbench has added one in recent years: https://dev.mysql.com/doc/workbench/en/wb-performance-explai...

> Is there something MariaDB doesn't have?

  * Proper native JSON support
  * Spatial support lags behind MySQL

However we are still using it in production and MySQL 8 is a no go given that it removed MyISAM support. We still use MyISAM due to fast inserts and easy backup (just copy the files). We use MariaDB for storing IoT time series data.

Have you explored the TokuDB storage engine? Or Aria?

Yes. Aria is one of the reasons we are using MariaDB in fact. It offers a great migration path from MyISAM. We migrated from MySQL 4.6, that's why our tables are in fact MyISAM. We currently have a test server running using Aria tables.

I have also thought about using TokuDB but SuSE (13.2) didn't ship a module for it then. I have to check again in 42.3.

The only real issues with MariaDB is lack of proper JSON and spatial support which would be of great use to us. I'm talking about a real JSON data type with validation and means to query and maybe even replace JSON, not a mere alias for the LONGTEXT data type.

We intend to switch to Postgres on the long run. It has everything we want, moreso with TimescaleDB extensions which could proove very useful for storing time series data. We are currently using it for the spatial database.

> Reliability: DDL statements have become atomic and crash safe, meta-data is stored in a single, transactional data dictionary. Powered by InnoDB!

To clarify, does this mean that DDL is now fully transactional the way it is in postgres?

This would be great if so, but it doesn't look like it:

https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html

> DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement. This means that DDL statements cannot be performed within another transaction, within transaction control statements such as START TRANSACTION ... COMMIT, or combined with other statements within the same transaction.

Sounds like it just means that single ALTER/ADD/REMOVE statements now cannot fail in an intermediate state, but a sequence cannot be run in a transaction, so there's still a manual process to unpick a migration that failed half-way through. (That's always fun in production...)

Perhaps the groundwork has been laid though, and it'll be possible in 9.0.

This is correct. DDLs are (still) auto committed, but they now cannot fail in an intermediate state. Discussing full transactional DDL should also take into account DDL being Replicated and on Online Schema changes (perhaps more important for Web-scale). Then it starts to become complicated supporting full transactional DDL (at the same time). But transactional DDL is absolutely a desired feature. Geir

> DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement.

That sounds horrifying. Implicitly committing transactions could very well leave the database in an undefined / inconsistent state, no? That is, from the applications view, if I do:

   BEGIN;
     STATEMENT A;
     STATEMENT B;
   END;

I would expect either both or neither to succeed, but that paragraph would suggest that A could succeed, and the transaction be committed. (And who knows after that?)

Am I missing something?

> That sounds horrifying.

That means any previous version could fail during DDL execution and leave your metadata in an inconsistent state that you couldn't recover.

Now MySQL is about as good as any commercial database.

Side question, but why the jump from 5.7 to 8.0?

What happened to 6.0 and 7.0?

Edit: found a kind of answer, though I never heard of 6 and 7 being "used" before. [1]

> Why did MySQL version numbering skip versions 6 and 7 and go straight to 8.0?

> Due to the many new and important features we were introducing in this MySQL version, we decided to start a fresh new series. As the series numbers 6 and 7 had actually been used before by MySQL, we went to 8.0.

[1] https://dev.mysql.com/doc/refman/8.0/en/faqs-general.html#fa...

People are going to start to think tech companies don't know how to count or something. Jokes aside... I'm wondering the same.

Oracle 18...

"start to think" ?

Microsoft went from Windows 2000 to Windows XP then to Vista and then to 7. If people haven't already been thinking that, this isn't what's going to start it, IMHO.

You forgot (especially you're counting consumer Windows, and 2000 was Server windows) 3.1 -> 95 -> 98 (OK. That was normal) -> ME -> XP -> Vista -> 7 (Which should have been 9 If I counted correctly) -> 8 (another OK count) -> 10 -> ? (I don't remember all the Windows 10 releases)

FYI, There always have been actual version numbers under the hood. They kind of messed up 7's number. I guess they had so much trouble changing things from 5.1 to 6.0, they decided another major version bump would be problematic. They apparently changed their minds with 10.

3.10 - 3.1

4.00 - 95

4.10 - 98

4.90 - ME

NT 5.0 - 2000

NT 5.1 - XP

NT 6.0 - Vista

NT 6.1 - 7

NT 6.2 - 8

NT 10.0 - 10

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...

Thinking about it, codebase-wise XP came from 2000 which came from NT4, which could be why 2000 became 6.

...Xbox, Xbox 360, Xbox One...

The usual radix promotion that tends to occur when the major version becomes ossified.

5.8.0 -> 8.0

In what way is 5.8.0 "ossified"? I swear you're just making up terms now :P ...

verb past tense: ossified; past participle: ossified 1. turn into bone or bony tissue. "these tracheal cartilages may ossify" synonyms: turn into bone, become bony, calcify, harden, solidify, rigidify, petrify "the cartilage may ossify" 2. cease developing; be stagnant or rigid. "ossified political institutions" synonyms: become inflexible, become rigid, fossilize, calcify, rigidify, stagnate "the old political institutions have ossified"

... it would seem to me by whatever logic is employed, the same thing will occur at 10.0 because the version format may "appear" to change (with 2 leading digits now).

Ohh ... maybe you're saying the 5 hasnt changed in ages, well now was a silly time to change it still because they were .2 releases until it did change, which was mentioned by the other poster that mysql has already used versions 6 and 7 prior ....

I still don't agree that ossified is a valid usage in this case (it was still .2 releases from changing) -- when the original x.y.z versioning scheme was defined it was understood that there could be 0-N minor "y" updates before X is incremented; that's by definition not ossification, simply the versioning scheme at work.

geez. what a mess versioning is ... :P

'become inflexible, become rigid, fossilize, calcify, rigidify, stagnate "the old political institutions have ossified"' this part

Another definition of ossified: cease developing; stagnate.

In other words, the major version became meaningless as the "minor" version changes when the major should

The same thing happened with Java. After Java 1.4 they just dropped the 1 and released Java 5.

React too - 0.14.9 -> 15.0.0

This confused me for ages. Only after reading your comment do I finally understand what happened here!

It was a bit weirder with Java, because Java 1.2 was widely marketed as Java 2. They then gave up on it a bit with 1.3 and 1.4, and then adopted it officially with 5.

Even weirder, 1.2 through 5 were all marketed specifically as Java 2, not just their second digit. So today you could be running Java 2 SE 5 Update 85.

> maybe you're saying the 5 hasnt changed in ages

Well, how could it be anything else? You have a major version that has been maintained since 2005 [0]

0 - https://en.wikipedia.org/wiki/MySQL#Release_history

MySQL 6 was used some 10+ years ago and has seen some alphas. Over time most things in there have been backported into the 5 series and some ideas for 6.0 didn't work out (i.e. Falcon storage engine) and were stopped. When/how 7 was used I'm not sure, but jumping from 5.7 to 8 simply drops the first digit, which was meaningless for a while already. (jumps from 5.5 to 5.6 and 5.6 to 5.7 were huge as well)

I have fond memories of playing with 6.0 Alpha and the Falcon engine.

And my favourite feature, the "BACKUP" command. Shame.

7 is used for MySQL Cluster, see also https://mysqlrelease.com/2018/03/mysql-8-0-it-goes-to-11/ Geir

> MySQL 8.0 delivers SQL window functions.

Great to see these in a MySQL release. Something so worth having I once had a script which would automate MySQL -> Postgres for data analytics purposes.

Does anyone have any idea when this will be available on Amazon RDS?

Default comment in such topics )

Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server at work and looking to migrate from postgres to MySQL for my personal ML projects.

Window functions have been a long time coming and I personally can't wait!

There are a lot of postgres fans on HN, would you mind giving some more info on why you want to go from PG to MySQL?

There are some nice features that MySQL lacks. Personally, the thing I like best in Postgres is transactional DDL. In MySQL, if halfway through a database transformation your migration script fails, you are in a broken state and you are on your own. Postgres rolls the whole transaction back. Ofcourse there are some other features MySQL lacks, such as variable length character columns (varchar) where you don't need to specify a maximum length.

The transactional DDL seems to be introduced in MySQL per 8.0 though

The advantages of Postgres (and MariaDB) over MySQL are pretty well traveled on HN. OP wants to move from Redshift Postgres & SQL Server to MySQL - which isn't something you see very often.

> The transactional DDL seems to be introduced in MySQL per 8.0 though

I thought so as well from the release note wording, thanks to theptip for confirming in the docs that DDL is not transactional in 8.0, just crash-safe. see https://news.ycombinator.com/item?id=16876549.

I did a project with postgres and symfony+doctrine.

At 80% of completion, I moved to mySql because I needed spatial index, I installed Postgis but got a lot of problems with doctrine-migration.

No explanation he could possibly give on HN will prevent him being down voted. Sad but true

As far as I am aware there is no good reason to not use MariaDB instead of MySQL. The creator of MariaDB, Monty Widenius, was on a episode of the changelog podcast if you want to hear some background as to why.

Former MySQL Product Manager here (no longer affiliated).

I've been to a Monty talk about this subject, and let me say it was interesting...

Monty starts by saying that he does not acknowledge MySQL 5.6's existence since some new features are an abomination (usually citing GTIDs).

He then compares MySQL 5.5 to MariaDB (of which MariaDB is based on MySQL 5.5; so it contains the superset of features).

MySQL 5.5 was released in 2010. Support for it will end at the end of this year.

Development has diverged a lot since 2010. For a more balanced comparison, I recommend this one: https://www.percona.com/blog/2017/11/02/mysql-vs-mariadb-rea...

We switched to MariaDB on freebsd 2 or 3 years ago. We ran into a couple performance-destroying bugs and while the devs acknowledged the issues, they made it clear they wouldn't be fixed any time soon. MySQL has been solid for us though.

Just a personal experience.

Monty is also the CTO of the MariaDB Corporation, which is a VC-funded entity. I would fully expect him to sing MariaDB's praises in a podcast.

Large companies have come to a different conclusion, at least so far. Among companies with very large database fleets, there's much greater usage of MySQL and Percona Server than MariaDB.

Granted, Linux distributions have leaned more towards shipping MariaDB by default instead of MySQL. This makes sense given that Oracle is, well, Oracle.

Redshift is forked off an ancient Postgres version, consider using a more recent (10 or 11 beta) real Postgres version.

Like AWS redshift the nosql database or what? What is redshift postgres?

AWS Redshift is their data warehouse database. It uses Postgres syntax. DynamoDB is their NoSQL offering.

Redshift is a columnar SQL database, based on an old version of PostgreSQL.

You want to go from Postgres TO MySQL‽ Why do you want to do that?

https://eng.uber.com/mysql-migration/

Uber really just needed a key/value store. MySQL works better when used that way since PostgreSQL has MVCC and can lead to table bloat and compaction issues.

I doubt many others ever encounter this issue since picking the correct data store is step 1.

InnoDB also has MVCC. Always has. It just uses a different strategy to avoid the table bloat and compaction issues.

Release looks great. I can't wait for MyRocks to arrive to make it even better.

I demand satiation.

Reply on news.ycombinator.com