Good that you brought it up. Such questions were actually considered, but the answers arrived at were always vague and changeable. Not surprising for a startup I guess.

Much of it will be read heavy, some parts will be write heavy. "Ideally", we should be using different solutions for the different needs, but that's too much at the beginning. So the best bet will be the best balance, while avoiding a database/backend restructuring to the extent possible. How much data: not surprisingly, it will start small, and the upper limit depends on the future...

Geographic based system, yes, eventually; but they both support geospatial. There will be time based queries for analytical and reporting purposes, not the core of the app. So that can easily be offloaded to a separate system.

The structure of the data will be mostly relational, so we stick with one of the old school systems. For the little bits that will be either dynamic or non-relational, both MySQL and Postgres now support JSON.

Popularity came into the equation because the more popular a system is, the more solutions are developed around it. So We won't be the first to tackle any problem in a popular system, thus reusing what others have done will be enough for the most part.

Cheers!