Нужно пойти от запросов которые вы будете к этой системе предъявлять.
В данной постановке - вам подходит всё что угодно. Берите PostgresQL.
Бесплатно и универсально.

Может подойти InfluxDb если основной вид запросов будет по интервалу времени.

Mongo КМК не подходит т.к. избыточно. Вам же только координаты передать и код смартфона.

Кстати да. Нарисуйте вашу главную табличку. (Концептуальную модель). И от нее можно
пойти с вопросами.

Я не знаю что такое "нехилые". Уточните цифры. Возможно то что вы считаете BitData - это вовсе не бигдата а просто
обычная современная БД.

В моём понимании биг-дата начинается от десятков и сотен терабайт. И от денормализации самих данных.

Areostar,

У вас будут транзакции, которые обновляют те данные, которые вставлены?

У тебя, получается write-only. Верно?

Я почему спрашиваю. Мы здесь за 1 итерацию не сможем выдать архитектурное решение которое покроет
все потребности. Может быть надо будет сделать 2-3 макета или POC прежде чем оно заработает.

Сейчас под требование автора подходят любые системы класса Event-Store, Time-Series DB (Influx).
Берите любую и она подходит. Это одна матрица. Если вы хотите поднимать на своем железе.
https://db-engines.com/en/ranking/time series dbms
https://db-engines.com/en/ranking/event store

Другая матрица - хостинг в Амазон и Гугл. У них EC2 стоят дороже. И лучше покупать не голую операционку
а службу как сервис и там будет другая матрица. И надо смотреть по деньгам как выходит.

Постргрес это просто серебрянная пуля которая всегда стрельнет но она может быть не такой быстрой
например по записи или не такой дешевой. Компромисс короче. Не имею ничего против MySQL.
Но я просто в нем не специалист.

Может на данной итерации (накопление гео-данных) вам вообще dbms не нужна и вам хватит
end-point который просто пишет все POST события в текстовый лог. А уже потом от запросов
бизнеса и производтсва можно этот лог перекладывать из одной системы в другую решая
сиюминутные задачи.

Dbf - это что? DBase? FoxPro?

По факту там может быть больше данных. Широта-долгота. Высота тоже может писаться. Скорость.
+Какая-то техническая хрень. И будет пухнуть datarow в этот бедный dbf. А беря во внимание что
dbf - не умеет поджимать nulls, получится не файл а .. пенопласт.

Он же говорит. Бизнес еще не определился с ТЗ.

Я думаю - в топике мало инфы и стоит подождать. Дизайн подсистемы хранения исторических
данных точняк должен отличатся от дизайна данных оперативных. Это вполне разумно.
Иначе владелец будет переплачивать в 1000% сам не зная за что.