I did all the following speed tests on a Win10/64 machine. The BSDDB database is on a SSD drive, the SQLite database for RootsMagic also.
0 in the table means that the search result was displayed (nearly) instantaneously so clocking the time was not possible (and would be quite irrelevant).
Another observation is that the place selector (7284 places) will be populated nearly instantaneously with 5.1.6 on BSDDB, but needs 1 - 2 sec with 5.2.2 on PostgreSQL. This observation matches the speed tests quite will. I have never noticed any significant performance difference between PostgreSQL and SQLite but I have no data for SQLite.
The situation where the speed problem of 5.2.2 is most annoying, is clearly the search for individuals. 5.1.6 on BSDDB is not really good (so I developed a solution outside of Gramps) but acceptable, but the factor of 4 for the time needed with 5.2.2 on PostgreSQL is simply inacceptable. I guess a quick work-around would be to make BSDDB available with 5.2.2 under the assumption that 5.2.2 will then be on the same performance level as 5.1.6.
And my personal opinion on the 13 sec with RootsMagic and the 640k dataset is that this isn’t really good either. A dataset of that size should be small change for SQLite if the indexes are well done, so I guess that the problem is located somewhere in the program code of RM.