News for hackers. Stuff that matters.
Re:Why Uber Engineering Switched from Postgres to MySQL (2016) by pilif on Monday June 11, 2018 @11:51AM (#17285287)
No matter the scale. Table corruption is never acceptable.

If table corruption is acceptable, you might as well just serve data from /dev/urandom and store user data to /dev/null.

Re:Why Uber Engineering Switched from Postgres to MySQL (2016) by astine on Monday June 11, 2018 @12:08PM (#17285462)
Table corruption may not be 'acceptable,' but that doesn't matter. Even if your software is perfect and has no bugs, it cannot account for issues at the system and hardware level. Backups and redundant systems exist for a reason. I've have data corruption in a PG database before. I don't remember the cause--I think it was the filesystem rather than Postgres that was at fault--but it still happened and I had to deal with it.
Re:Why Uber Engineering Switched from Postgres to MySQL (2016) by manigandham on Monday June 11, 2018 @05:36PM (#17288822)
Obviously the situation being discussed here is corruption specifically because of the database software. If a comet destroys the entire datacenter and the data is lost, nobody is going to blame Postgres for it.