Почему для Bean Remote я выбрал PostGIS вместо ORM

В Bean Remote я решал ключевую задачу: быстро показывать кафе на карте с фильтрацией по радиусу и видимой области.

Для такого сценария обычный ORM-уровень оказался менее эффективным, чем нативные geospatial-возможности PostgreSQL.

Стек проекта

  • React Native + Expo
  • Node.js + Express
  • PostgreSQL + PostGIS

Почему PostGIS оказался лучше

1) Нативные пространственные индексы

location GEOGRAPHY(Point, 4326)

CREATE INDEX idx_cafes_location ON cafes USING GIST (location);

И затем:

SELECT * FROM cafes
WHERE ST_DWithin(
  location,
  ST_SetSRID(ST_MakePoint(:lng, :lat), 4326),
  :radius
);

Это даёт предсказуемую скорость и точность без пост-обработки на стороне приложения.

2) Сложные geo-операции в ORM часто неудобны

При работе с ST_DWithin, ST_Intersects, ST_MakeEnvelope всё равно приходится уходить в raw SQL. В итоге дополнительный слой абстракции не упрощает, а усложняет критические геозапросы.

3) Удобно объединять бизнес-логику и геометрию в одном запросе

SELECT * FROM cafes
WHERE is_verified = true
  AND ST_Within(
    location,
    ST_MakeEnvelope(:west, :south, :east, :north, 4326)
  );

Сравнение подходов

КритерийORMPostGIS
CRUDХорошоХорошо
Пространственные функцииОграниченноПолноценно
ИндексыЧасто вручнуюНативно
Реалтайм-картыСреднеОтлично

Вывод

Для обычных приложений ORM может быть отличным выбором. Но если у вас геоданные, карты и высокая частота spatial-запросов, PostGIS даёт больше контроля и скорости.

В Bean Remote это позволило сделать интерфейс карты ощутимо быстрее и упростить серверную логику.

Полезные материалы