Earlier quoted context omitted.
Define: "complicated"
PostgreSQL: "your date 2020-02-31 isn't a date, fix that" MySQL: "2020-02-31? Whatever man, I'll just enter something..."
Why Uber Engineering Switched from Postgres to MySQL (2016)
11–20 of 133 posts
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#12Earlier quoted context omitted.
PostgreSQL: "your date 2020-02-31 isn't a date, fix that" MySQL: "2020-02-31? Whatever man, I'll just enter something..."
Considering the US uses a weird date format, I definitely prefer the former in combination with input sanitation forcing you to thing about your actions before assuming the database will fix it for you.
Another example of a database doing improper things would be Oracle mixing up the empty string with NULL. In Oracle, both are the same...
MySQL has a few more of those gotchas, e.g. regarding broken charsets (UTF-8 isn't 'utf8', it is 'utf8mb4', 'utf8' is an alias for 'utf8mb3' which is a broken subset). I wouldn't use MySQL for any data that was important to get back consistently. However, since Uber seems to be using some schemaless "we don't care"-layer anyways, that point is moot for the original article.
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#13Earlier quoted context omitted.
Define: "complicated"
Just creating a new user is annoying enough. Permissions are also much more complex. What the hell are schemas?
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#14Earlier quoted context omitted.
PostgreSQL: "your date 2020-02-31 isn't a date, fix that" MySQL: "2020-02-31? Whatever man, I'll just enter something..."
That doesn't exactly sell me on MySQL, sounds like a recipe for disaster
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#15Has Postgres architecture changed since Postgres 9.2 in terms of the inefficiencies mentioned in the article?
"Highly advanced" databases give both options, but AFAIK, MySQL/PGSQL will likely not offer this, at least for a very long time, since it requires radical changes.
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#16Has Postgres architecture changed since Postgres 9.2 in terms of the inefficiencies mentioned in the article?
Uber has not switched from Postgres used as RDBMS to MySQL used as RDBMS, they switched from Postgres used as RDBMS to MySQL used as key-value storage layer of homegrown sharded non-relational database.
This has pretty much no bearing on anyone using Postgres or MySQL in reasonable way.
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#17Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#18Earlier quoted context omitted.
Define: "complicated"
Just creating a new user is annoying enough. Permissions are also much more complex. What the hell are schemas?
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#19Started using Postgres a couple of years ago, and I now can't believe I ever lived without window functions, native arrays, custom types, etc.
Re: Why Uber Engineering Switched from Postgres to MySQL (2016)
#20Earlier quoted context omitted.
Just creating a new user is annoying enough. Permissions are also much more complex. What the hell are schemas?
Schemas are similar to databases in mysql. They serve as a namespace. In mysql you can have a database `foo` and a table `foo.bar`. In postgres you can have a schema `foo` and a table `foo.bar`. In postgres you can have multiple databases in a cluster, and multiple schemas within each of those databases.