Нужно пойти от запросов которые вы будете к этой системе предъявлять.
В данной постановке - вам подходит всё что угодно. Берите 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% сам не зная за что.

Разведка - боем. Почитал про Mongo. Да. Действительно добавили поддержку географических типов и
вроде-бы даже spatial-index поддерживается.

В своих докладах главный постгресщик Бартунов постоянно хвастается что дескыть PG обгоняет
Mongo на поисковых операциях по BSON объектам. Интересно догадался ли он поддержать
спецификацию GeoJSON.

Где то тут видел. Ближе к концу.

[spoiler]

Сейчас посмотрел вот этот документ https://www.percona.com/live/e17/sites/default/files/slides/High Performance JSON - PostgreSQL vs. MongoDB - FileId - 115573.pdf

На ихних тестовых конфигурациях на операции

SELECT
12 ms - Mongo
3 ms - PG

INSERT
13 ms - Mongo
4 ms - PG

Но эти данные все равно сейчас никак не натягиваются на постановку автора. КМК ему все равно как грузить.
С лагом в 10 мс или в 1000. Это ни на что не влияет. Операции - рассеянные. Рандомные.

А выборки ему надо делать по срезу ID-устройства и диапазону времени. Это совсем не тот тип транзакций которые
меряет percona. Там - скорее всего гоняют точечные OLTP выборки по 1 атрибуту.

Поэтому - макет и еще раз макет.

Да читал я до конца. Постргесщик должен быть рукастым админом вобщем-то.
Смысл теста я увидел в том что величины ОДНОГО порядка. Хотя бы не в 10 и не в 100 раз
отличаются.