Row count can be a poor indicator of how well an RDBMS can perform; the data-types used, number of columns, how you index and how you join other tables has a massive impact. I’ve seen smaller databases with terrible performance vs larger ones with no such issues. A common mistake is joining more than 7 tables in a single query - the query engine just cannot comput all the different possible ways of joining the tables so never a picks a plan that is ‘good enough’ times out, and just finds a way to do it that might be terrible.
Both PostgreSQL and MySQL have lot’s of plugins (and forks) available that help achieve specific goals. With a propriarty database companies have to wait for the vendor to decide to adopt such a feature e.g. SQL Server has only recently adopted support for JSON where as PostgreSQL has supported it one way or another for a number of years.
Generally if you are buiding a webapp and you plan to keep moat logic in the app layer and use a database as a datastore MySQL will probably be fine. If you plan to actually use a database prop[erly, and get it to do the work of dealing with the data PostgreSQL will often be a better bet for reasons already explained.
If used properly (and optimised and played to its strengths) there shouldn’t be many reasons why you would find any of the common RDBMS’ as lacking in performance, but unfortunately most developers barely scratch the surface of database functionality and will often reinvent functionality that might already exist. Where I currently work we have a lot of developers that get described as ‘full stack’ and the DBA’s are kept very busy