36
votes

I am working on a web/mobile application based on location data. Since i am already familiar with MongoDB, i found the geospatial indexing of mongo is quite suitable for my needs. As i am mainly dealing with simple/short location points, Mongo 2d indexing is good for me.

Along the way i picked PostGIS, because of its stable/mature way. And its awesome feature set. But my main concern is performance since my data is heavily dependent on location(mostly 70 - 80% of the db calls deal with the location).

I like mongo because its used by high performance web apps like foursquare already. But i have seen PostGIS is mainly used in government/enterprise projects (mostly non web/mobile apps). So i am little confused right now to choose the right GIS db for my web/mobile app? Got any suggestions?

1
  • 2
    create spatial index with postgres/postgis and you will see good performance. But if you are happier with MongoDB then continue with that.
    – Mapperz
    Commented May 17, 2011 at 17:13

3 Answers 3

36
votes

If your write load (incoming data stream) can potentially grow without limit (if the success of your web project will cause the amount of writes to grow grow grow) then go with Mongo, because it will be very hard to architect your way around the write bottleneck in PostGIS/PostgreSQL once you grow beyond the capabilities of a single high-end server (which, it mush be noted, are pretty darn huge).

You can architect good PostGIS/PostgreSQL solutions for heavy read load (master/slave replication) and for huge data sizes (table partitioning) but write load is difficult. You've already laid out the case against Mongo and for PostGIS, which is the much larger feature set and code maturity of PostGIS, so balance that against the other concerns.

5
  • 3
    Oh, and remember, "MongoDB is web scale". xtranormal.com/watch/6995033/mongo-db-is-web-scale Commented May 17, 2011 at 17:16
  • yeah i know that.. it was really funny (and hit right in the head if you just wanted to fancy yourself with the latest tech) :)
    – RameshVel
    Commented May 17, 2011 at 17:20
  • 1
    Well, you can always "webscale" by turning fsync = off ;) Commented May 18, 2011 at 5:01
  • 1
    PostgresXC can now provide a write-parallel system with full transactional guarantees and multi-node query execution. Belt and suspenders, OLAP and OLTP, worth looking at. And it supports PostGIS. Commented Mar 8, 2013 at 17:53
  • But if you choose PostgresXC/XL, you will need to maintain the package yourself. Its officially only available for Fedora/Redhat, Ubuntu lovers have to spend time compiling things manually.
    – Ravi Kumar
    Commented Apr 19, 2015 at 15:05
21
votes

I've been using PostGIS for a few years and only recently started to investigate how I could use MongoDB to deal with certain use-cases. I was dealing with point data that had sparse fields - like OSM data with a varying number of tags per record, and since MongoDB has no schema, it lends itself well to this. I loaded a sample of this data into an instance of each DB and this is what I found.

It appears to me that for simple storage and retrieval of point data Mongo works just fine. The bounding box geospatial queries seem to work well, and I find that the overall performance is very good. It also is very easy to setup and get going, although I have found that the mongoimport tool does not allow me to define a compound 2D coord field in a TSV or CSV file. Since it's pretty easy to write a script that generates JSON, this hasn't been much of a problem. Its major drawback at the moment is that almost nothing else in the geospatial realm can natively read data from it. There appears to be an experimental Mapnik datasource plugin at https://github.com/springmeyer/mapnik-mongo, but that's all I could find.

PostGIS on the other hand takes a bit longer to set up (at least for me), but as was mentioned above, it provides way more features right out of the box. In addition to providing much more sophisticated spatial analytic capability, it is also natively supported by a ton of other applications and libraries; Mapserver, Mapnik, QGis, GDAL, etc, etc. To me, PostGIS is much more a true GIS system, rather than a simple storage and retrieval system.

As far as performance goes, I found that I could retrieve data very quickly from both systems. However, it seemed like PostGIS benefited more from the presence of indexes. MongoDB was slightly faster at returning the entire data set to me (2 million records) at once, and slightly slower at returning a query that used an index - the first time. I'm not exactly sure of the mechanism that it uses for caching, but I can see that if I repeat a query in MongoDB, the results come back much more quickly the 2nd time around. I see something similar in PostGIS, but not to the same degree. I did also note that the memory usage on my machine seems to be far higher with MongoDB running than it is with PostGIS.

So, my conclusion is that I'm not going to get rid of PostGIS as my default geospatial storage and analysis system, but for certain types of projects (namely web maps that display image tiles and/or point data) I may consider using MongoDB as my data store.

Roger

3
  • 1
    i absolutely agree with you.. mongo is very good option handling basic Geo data. currently am doing simpler spherical and bounding box queries, and its doing well.. One more thing i want to add is Solr lucene also providing the basic geo functions as mongo, and its quite fast too when using with faceted queries. currenlty am using the combination of both mongo & Solr..
    – RameshVel
    Commented Jul 28, 2011 at 6:56
  • @RameshVel could you tell something more on solr lucene?
    – rkm
    Commented Jan 5, 2013 at 8:43
  • @rashad, you can install elasticsearch (just download, extract and done), and play with Geo DSL queries. Its pretty basic, but if you want search/facets as well as geo, you can use it.
    – Ravi Kumar
    Commented Apr 19, 2015 at 15:08
3
votes

Regarding the memory usage with Mongo it's worth pointing out that Mongo relies entirely on the OS file cache to get its indices and data into memory - there's no concept of a 'mongo memory buffer / index cache', so you will see it try (or rather, the OS will use) all the available RAM up to the point where all your data files have been cached.

Not the answer you're looking for? Browse other questions tagged or ask your own question.