PostGIS

PostGIS is PostgreSQL plus the spatial extension, and AddisDB gives it its own engine entry for one reason: geometry columns are decoded to GeoJSON on the backend, so a query that returns geometry gets a Map tab you can click straight into.

Who it is for

PostGIS is the reference implementation of spatial SQL. Points, lines and polygons become real column types with real indexes, so "which delivery zones does this address fall inside" is a join, not a batch job in another system.

The performance story is one index type: GiST over a geometry column, which lets the planner discard almost everything by bounding box before running the expensive exact test. A spatial query without that index is a full scan calling a geometry function per row — the difference is usually orders of magnitude.

Use it for logistics and routing, asset and territory management, store locators, environmental and planning data — anywhere location is part of the domain rather than an afterthought.

Set up the extension

1. Managed Postgres almost always ships PostGIS. On Neon, Supabase, RDS and Cloud SQL you only need to enable it.
2. Run CREATE EXTENSION postgis; in the database you want spatial support in — it is per-database, not per-server.
3. Self-hosted: install the postgis package for your Postgres version (brew install postgis, apt install postgresql-16-postgis-3), or use the postgis/postgis Docker image which has it preinstalled.
4. Verify with SELECT postgis_version();
5. Index every geometry column you filter or join on, and store one SRID per column so comparisons never silently cross coordinate systems.

CREATE EXTENSION IF NOT EXISTS postgis;
SELECT postgis_full_version();

-- the index that makes spatial queries fast
CREATE INDEX zones_geom_idx ON zones USING gist (geom);

Connect from AddisDB

1. New Connection → PostGIS under Relational / SQL. Port prefills to 5432, exactly like Postgres — it is the same server.
2. Fill host, port, database, username and password, or paste a connection URL and click Fill fields.
3. Set SSL mode to require for a managed database.
4. Test, then Save.

Geometry on the map

Run any query that returns a geometry column and a Map tab appears next to Table, Text, Chart and JSON in the results toolbar. Click it and your features are drawn on an interactive map, with a basemap switcher you can change live in Settings.

AddisDB reads geometry columns directly, so you do not need to wrap anything in ST_AsGeoJSON — though if you already have WKT text, or you select ST_AsText(geom), that is recognized too.

The map draws what your query returned. A WHERE clause is the quickest way to make a dense layer readable, and a ST_Simplify around the geometry is the quickest way to make a heavy one draw fast.

The two mistakes that cost the most time

• Mixing SRIDs. A geometry stored in 4326 (degrees) compared against one in 3857 (metres) either errors or returns nonsense. ST_Transform converts; ST_SetSRID only relabels.
• Measuring distance in degrees. ST_Distance on 4326 geometry returns degrees, not metres — cast to geography, or transform to a projected SRID, when you want a real unit.

-- Metres, not degrees
SELECT name, ST_Distance(geom::geography, ST_MakePoint(-77.03, 38.90)::geography) AS metres
FROM   stores
ORDER  BY metres
LIMIT  10;

Everything Postgres gives you, too

• The full schema diagram, in-grid editing, and ⌘K search across every object.
• Live Monitor with active queries, blocking, locks and the flight recorder — spatial queries are exactly the kind that need watching.
• Test clones — dry-run a spatial migration against a disposable copy of the database, data and all.
• Mock data from your real schema, and AI querying that knows your tables.
• Migrations and schema diff through Drizzle Kit or Prisma.