The SQL vs NoSQL database for storing users data from mobile sensors (GPS ,accelerometer, etc)

It really depends on your application needs. Let us see, for example, a chat app, to better understand what db to choose.

A chat app has about 50/50 read/writes. Now, lets say our db is a MySQL. Going to production we will create a master/slave, cause that is the topology MySQL supports. At some point we will have performance issues, and our bottleneck will turn out to be the master. Why? Because only a master writes and slaves follow. Each change in the db oplog is transmitted to the slaves to be replicated. You can tell the master to only write to it and return success and slaves to update async, but then, your reads will be inconsistent, or you can tell the entire cluster to replicate the write and then return write success response, but that is even more of a performance bottleneck? What did I demonstrate? The trade-offs you must take according to your application needs. It is called the CAP theorem. It states that you can only choose at best 2 of the 3 letters to your advantage in expense of the remaining letters. CAP - Consistency, Availability, Partition tolerance.

Now, going back to SQL/NoSQL.

SQL databases allow transactions, which is like a contract saying, either commit all of what I gave you or nothing. A NoSQL database gives you the opportunity to arrange your data in a different way but they do not offer transactions. Instead each of them handles reads/write in a different way. For example, for our chat app, I would choose a really fast write db, like Cassandra (works like an append only log). Cassandra's nodes are all equal, no master or slave configuration, which means every node accepts reads/writes. That is great, but I still have a problem with the read inconsistency. Well, that problem can be partially addressed with something called a quorum. Basically it means, I prefer more consistent read in my apps DB over availability, which is completely fine and still a heck of a lot faster than MySQL. Cassandras default replication factor, for X nodes, is X. For 3 nodes, replication factor will be 3, which means all of our data will be replicated 3 times and our local quorum (how many nodes must respond to the operation) will be 3/2 + 1 -> 2

LOCAL_QUORUM = (replication_factor/2) + 1 

So with 3 nodes, each read/write must pass the coordinator(the node which decides where to send the read/write) + pass 2 nodes defined by the local quorum configuration.

The above was just an example attempt with Cassandra, it is a very complicated database, as the subject about databases in general.

In Conclusion:

if you need fast writes + fast reads -> you must make a decision between consistency, high availability and partition tolerance + appropriate db.

if you dont care about writes and need fast reads -> a db that is fast in reads + consistency

if you need transactions -> SQL type db

Last but not least, a lot depends on how you model your data and components intercommunication.