Hacker News Reader

Comment by duaneb | Hacker News Reader

I wish it didn't depend on MongoDB. Is there a good reason for not using a more general purpose database, like SQL or any of the billion key value stores out there?

View on HN

We picked MongoDB a while ago because of its built in geospatial indexing support. Would be happy to add support of other databases. Any strong candidates on top of your head?

PostgreSQL / PostGIS

RethinkDB!

Both Postgres and SQLite have extensive geospatial support (PostGIS and SpatiaLite respectively), including indexing and boatloads of useful geospatial functions. And in my experience, both of them are far more advanced than Mongo's geospatial support.

I know it's a pain to get data into it, but how about Big Query?

Ideally open-source. Surprised MongoDB 2.2+ is such an issue but thanks for the feedback and suggestions. We'll look into PostgreSQL, Riak and RethinkDB.

It is based on an open-sourced db called Dremel:

https://code.google.com/p/dremel/

But dremel doesn't support incremental updates. Dremel is designed for read-only data. All its columns are indexed. The whole table needs to be re-built after update.

I haven't worked with geospatial databases as much (so verify this with someone who has), but Postgres is a good bet for an alternative to mongo in this scenario.

MongoDB is used as the datastore for unstructured data, e.g. item attributes and user attributes. It's also used as a cache for prediction results, so queries like geospatial search can be performed.

There is no specific reason reason to stick with MongoDB only. It just happens to be the database the team has picked for the first implementation. It is very likely to support other databases in the coming future given the strong community demand.

Reply on news.ycombinator.com