MongoDB — when does a document database make sense

Relational databases solve 90% of our needs. But what about the remaining 10%? Logs, events, flexible forms, data without a fixed schema. For these cases we tried MongoDB — and discovered that NoSQL is neither magic nor a threat.

Use case: IoT sensor data¶

Each sensor type sent different data in a different format. In a relational database, we would need an EAV model or dozens of tables. MongoDB allows you to store a document exactly as it arrives.

Schema-less does not mean schema-free¶

The biggest myth. Even in MongoDB you need conventions. Without them you end up with inconsistent data — “createdDate” in one place, “created_date” in another. We introduced Mongoose for schema enforcement at the application layer.

Indexes and the aggregation pipeline¶

db.readings.createIndex({ sensorId: 1, timestamp: -1 });
db.sensors.createIndex({ location: "2dsphere" });
db.logs.createIndex({ createdAt: 1 }, { expireAfterSeconds: 2592000 });

The aggregation pipeline in MongoDB 2.6 is surprisingly powerful. GROUP BY, JOIN (lookup), transformations — all in a single pipeline.

When YES, when NO¶

YES: Variable schema, hierarchical data, prototyping, geo queries. NO: Transactional systems (without multi-document ACID), complex reporting, small projects.

The right tool for the right problem¶

MongoDB is not a replacement for a relational database; it is a complement. PostgreSQL for transactional data, MongoDB for sensors and logs. The key is not to get carried away by the hype.