Haven't done anything much with the spatial datatypes and functions but I can make some comments on DBMSs in general.
Firstly I strongly doubt that you'll find a significant difference in performance between the two. Sure one may be faster than the other for this or that but overall they are probably going to be fast enough. If your choice comes down to just that difference then you'll need to benchmark, tune and failing anything else apply additional hardware resources.
MySQL for example has multiple storage choices and other tuning options that can greatly affect performance. Some people argue that it foregoes normal DBMS functionality for speed but this is less the case since V5.
In any case, aim for database independence. Design it to run on any DBMS that supports spatial functions. There are ways to insulate your code from DBMS particulars. That way you can easily use either - or a third option that comes along later.
You'll probably also find that compared to your own code the outright performance of the DBMS functions could be slower. This can be offset if you are using a DBMS anyway to store the data. Depending upon the DBMS and your design, a lot of work can be avoided by the DBMS optimiser. It might for example screen out records based on spatial criteria and thus not even return them to your application.
Considering the DBMSs, I view PostgreSQL as being solid and complete. 'Mature' would be the summary in a single word.
MySQL is more up and coming. Not quite there as a complete DBMS but almost certainly good enough for what you want. There is a lot of support and some nice tools out there for it.
Summary - Design for independence and choose either. Slight preference here for PostgreSQL.
Firstly I strongly doubt that you'll find a significant difference in performance between the two. Sure one may be faster than the other for this or that but overall they are probably going to be fast enough. If your choice comes down to just that difference then you'll need to benchmark, tune and failing anything else apply additional hardware resources.
MySQL for example has multiple storage choices and other tuning options that can greatly affect performance. Some people argue that it foregoes normal DBMS functionality for speed but this is less the case since V5.
In any case, aim for database independence. Design it to run on any DBMS that supports spatial functions. There are ways to insulate your code from DBMS particulars. That way you can easily use either - or a third option that comes along later.
You'll probably also find that compared to your own code the outright performance of the DBMS functions could be slower. This can be offset if you are using a DBMS anyway to store the data. Depending upon the DBMS and your design, a lot of work can be avoided by the DBMS optimiser. It might for example screen out records based on spatial criteria and thus not even return them to your application.
Considering the DBMSs, I view PostgreSQL as being solid and complete. 'Mature' would be the summary in a single word.
MySQL is more up and coming. Not quite there as a complete DBMS but almost certainly good enough for what you want. There is a lot of support and some nice tools out there for it.
Summary - Design for independence and choose either. Slight preference here for PostgreSQL.