Чому для 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 це дало помітно кращу швидкодію і простішу серверну логіку.

Корисні матеріали