Postgres 9.1 vs Mysql 5.6 InnoDB?

Question

Simple question - what would better for a medium/big size database with requirement for compatibility with ACID in 2012.

I have read it all (well most) about mySQL v

Answer 1

PostgreSQL is a lot more advanced when it comes to SQL features.

Things that MySQL still doesn't have (and PostgreSQL has):

• deferrable constraints

• check constraints (MySQL 8.0.16 added them, MariaDB 10.2 has them)

• full outer join
  MySQL silently uses an inner join with some syntax variations:
  https://rextester.com/ADME43793
  

• lateral joins

• regular expressions don't work with UTF-8 (Fixed with MySQL 8.0)

• regular expressions don't support replace or substring (Introduced with MySQL 8.0)

• table functions ( select * from my_function() )

• common table expressions (Introduced with MySQL 8.0)

• recursive queries (Introduced with MySQL 8.0)

• writeable CTEs

• window functions (Introduced with MySQL 8.0)

• function based index

• partial index

• INCLUDE additional column in an indexes (e.g. for unique indexes)

• multi column statistics

• full text search on transactional tables (MySQL 5.6 supports this)

• GIS features on transactional tables

• EXCEPT or INTERSECT operator (MariaDB has them)

• you cannot use a temporary table twice in the same select statement

• you cannot use the table being changed (update/delete/insert) in a sub-select

• you cannot create a view that uses a derived table(Possible since MySQL 8.0)

    create view x as select * from (select * from y);
  

• statement level read consistency. Needed for e.g.:
  update foo set x = y, y = x or
  update foo set a = b, a = a + 100

• transactional DDL

• DDL triggers

• exclusion constraints

• key/value store

• Indexing complete JSON documents

• SQL/JSON Path expressions (since Postgres 12)

• range types

• domains

• arrays (including indexes on arrays)

• roles (groups) to manage user privileges (MariaDB has them, Introduced with MySQL 8.0)

• parallel queries (since Postgres 9.6)

• parallel index creation (since Postgres 11)

• user defined data types (including check constraints)

• materialized views

• custom aggregates

• custom window functions

• proper boolean data type
  _{(treating any expression that can be converted to a non-zero number as "true" is not a proper boolean type)}

When it comes to Spatial/GIS features Postgres with PostGIS is also much more capable. Here is a nice comparison.

Not sure what you call "ease of use" but there are several modern SQL features that I would not want to miss (CTEs, windowing functions) that would define "ease of use" for me.

Now, PostgreSQL is not perfect and probably the most obnoxious thing can be, to tune the dreaded VACUUM process for a heavy write database.