Redacted DevWorks

When I found out how powerful PostGIS was, I was gobsmacked. No matter how ridiculous that sample data I'd provide, the results would be fast and come back accurate and consistently.

The only other database engine that offered decent GIS indexing and searching, was ElasticSearch. But ES is not an ACID adhering engine, and is specifically designed to be a screaming fast fulltext search engine first, and everything else second. You never want ES to be your primary database engine (it's not designed for that anyways), it should always be a compliment to your more stable and consistent database solution.

Simply put, I could have stuck to a MySQL + ElasticSearch solution, but the operating costs around that get astronomical when you get down to ho HEAVY ElasticSearch is, and how expensive it is to operate in the any hosting solution.

PostGIS allows to me not need ES for geospatial indexing and querying, and to be really fast at it while doing it. A god send.

While there's been some very clever techniques that has allowed non-natively supported geo querying to be performed, it is incredibly slow in the long game and error prone at best.

MySQL finally introduced it's own GEO functions and special indexing operations for GIS type data. I prototyped with this, as MySQL is the most familiar database to me. But no matter what I did with it, how much tuning i'd give it, how much I played with it, the results would come back inconsistent.

It was very disappointing.

I figured, at this point, that SQL Server, being an enterprise solution authored by one of the biggest worldwide software developers in the world, Microsoft, might contain some decent GIS in it.

I was very disappointed.

Postgres is a Database solution i'm still getting familiar with, but I noticed it had no built in support for GIS. So I hilariously didn't pay it too much attention. That was until I stumbled upon PostGIS and my world changed forever.