Postgres doc says:
B-tree, GiST and SP-GiST indexes
Short-term share/exclusive page-level locks are used for read/write access. Locks are released immediately after each index row is fetched or inserted. These index types provide the highest concurrency without deadlock conditions.
MySQL doc says:
A record lock is a lock on an index record. For example, SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; prevents any other transaction from inserting, updating, or deleting rows where the value of t.c1 is 10.
Record locks always lock index records, even if a table is defined with no indexes...
It seems like Postgres locks a page while MySQL only locks a row when updating/inserting/deleting a row.
Based on this information, in terms of locking, I expect MySQL to be more tolerant to parallel write-heavy applications than Postgres.
Am I understanding this correctly? Or, is there something fundamentally different between the two DBMS that I missed?
This is not a question that asks your opinion on whether Postgres and MySQL is better. Please focus on the lock aspect.
This question fits Stackoverflow because it is about software tools commonly used by programmers.
I'd say that the two quotations are talking about two different things: the PostgreSQL documentation is talking about a very short-term lock, while the MySQL documentation is talking about a lock that is held until the end of the transaction. So I don't think you can make deductions about the performance under concurrency based on these quotations.
My recommendation is to build and run a little benchmark that reflects your intended usage.