Agreed, this seems silly to build your own which likely performs worse than PosgGIS and has way more bugs.

At least the article could have addressed why that would not work for their use case.

edit: also now they have to classify polygons into groups that wholly fit into some "city" polygon. That seems like it becomes a pain to maintain since you may want to expand a region in the future and it happens to go outside of your previously defined "city". Or maybe you want a region that isn't in a "city", like a "country" or "mid-atlantic" region.

Modern tech companies have a penchant for solving the same problems less efficiently using the latest tech. shrugs

Most things at Uber were first built in the natural "why don't you just" way. Python/Flask monolith, Postgres, haproxy, etc. They are being replaced with fancier distributed systems (microservices, Schemaless, Ringpop, etc) by necessity.

Has the transaction rate surpassed what you can get out of Postgres? If not, what is the necessity for the change? Just curious. Thanks for any insight.

Increased latency, probably. They said they wanted 99% of queries to be 100ms or less. When I use the pgAdmin and run EXPLAIN ANALYZE SELECT 1; I get 0.025ms execution time, but it takes 62ms to send and recieve that.

Latency is not an issue. That your test took 62ms to send and receive that is an artifact of your setup.

Eg. latency across availability zones in the same EC2 region is <2ms (and obviously even faster in the same AZ)

NIH syndrome https://en.wikipedia.org/wiki/Not_invented_here

Or MongoDB geospatial indexing? I used it for a project that required a similar approach (point in polygon). It was quite easy to setup and use, at least at a small scale.