Warum ich bei Bean Remote PostGIS statt eines ORM gewählt habe

In Bean Remote musste ich ein Kernproblem lösen: Cafés auf der Karte schnell nach Radius und sichtbarem Kartenausschnitt filtern.

Für diesen Use Case war ein klassischer ORM-Layer weniger effektiv als die nativen Geofunktionen von PostgreSQL.

Stack

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

Warum PostGIS besser passte

1) Native räumliche Indizierung

location GEOGRAPHY(Point, 4326)

CREATE INDEX idx_cafes_location ON cafes USING GIST (location);

Dann:

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

Das liefert saubere Performance und hohe Genauigkeit ohne zusätzliche App-Filterung.

2) Komplexe Geo-Operationen sind in ORMs oft umständlich

Bei ST_DWithin, ST_Intersects oder ST_MakeEnvelope landet man ohnehin häufig bei raw SQL. Der zusätzliche Abstraktionslayer hilft dann in den kritischen Pfaden kaum.

3) Business-Regeln und Geometrie in einem Query

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

Vergleich

KriteriumORMPostGIS
CRUDGutGut
Räumliche FunktionenBegrenztVollständig
IndexoptimierungOft manuellNativ
Echtzeit-KartenMittelSehr gut

Fazit

Für viele Anwendungen sind ORMs sinnvoll. Bei Karten, Geodaten und vielen Spatial-Queries bietet PostGIS deutlich mehr Kontrolle und Geschwindigkeit.

In Bean Remote hat das sowohl die Performance verbessert als auch die Backend-Logik vereinfacht.

Weiterführende Quellen