MySQL or PostgreSQL for geoqueries?

Question

MySQL

Before the start of the project, there is a choice of technologies, and more specifically, a database.
The project will contain geo-queries, that is, the system determines the user's location and ranks the issue in such a way that there are goods on top, from suppliers from a radius of 100 km.
It is also planned to configure the search in such a way that the product with the article "H-DRS-50V-UI310" is found on requests:
HDRS-50V-UI310, H-DRS50V-UI310, etc.
The programmer insists on MySQL the way he has always worked with it and it is convenient for simple queries.
I (the customer), after reading the Internet, tend to PostgreSQL because it already has PostGIS for geoqueries, it has full-text search, and in general it is more serious than a muscle in my opinion.
The project will not be small: about a million products, about three million product offers for these products from different suppliers. Various sorting by characteristics, manufacturers, etc. Automatic selection of analogues. Syntax analysis of product names in a category to automatically identify a new product in the desired category and other goodies.
Of course, you can start on MySQL, but will the question of switching to PostgreSQL arise later?
Or in an order to say that the development was carried out on PostgreSQL?
Or the muscle will pull it all without problems?

Answer 1

PostgreSQL + PostGis (OSM runs on this bundle, a very fast and reliable system)
With MySQL, you can always switch to PostgreSQL, but back is more difficult. Especially if PostgreSQL features are used.
Better to start right away with PostgreSQL

Answer 2

I vote for postgres

Or in an order to say that the development was carried out on PostgreSQL?

you will have to order only if you tie a muscle

The project will not be small: about a million products, about three million product offers for these products from different suppliers.

medium, to the upper level of the average is still very far away

full text search

this requires integrating shinxsearch

Various sorting by characteristics, manufacturers, etc.

depends on the structure of the database

Automatic selection of analogues

does not depend on the DBMS, you need to write your own solution or stupidly add it manually

Syntax analysis of product names in a category to automatically identify a new product in the desired category and other goodies.

does not apply to the DBMS at all, a separate solution, with a large share of manual work (at the beginning)
Easier / cheaper to poke at suppliers with a stick and force them to form price lists with the same SKU

Answer 3

Definitely postgres.
Muscle is designed for small and high-speed databases, its task is to quickly issue data from a (relatively) small and (relatively) simple database structure. Well, at least that's how it was originally intended. Muscle is fast.
Postgres was originally designed for serious projects, with serious databases - a sort of open source oracle. But in tasks where the muscle flies like a bird of God, postgres can toss and turn like its own avatar - an elephant :) This is the price for seriousness.
But in your case, in general, there is no choice :) on a million records, muscle will simply fall :)

Answer 4

IMHO, elasticsearch is better for your task. But not as the main database, but as indexes for filtering by parameters and boosting (complex ranking) by partial match and distance.