MongoDB

MongoDB is an open-source document-oriented non-relational database management system that supports various forms of data. We use it when a specific project's volume or data structure does not fit the classic relational DBs.

Documents, not tables

For a long time, relational DBMSs were the only viable solution for storing and managing data. Since the mid-2000s, we've had other options!

Traditionally, data has always been organised in tables, each with a finite number of columns and populated by homogeneous records. This structure has limitations in some scenarios; alternative approaches have emerged since the mid-2000s thanks to advances in the hardware field (SSD and RAM above all). One of these is the use of a 'documentary' approach in which heterogeneous records are organised in 'collections' and indexed by means of a key. The absence of a pattern is fundamental, meaning records belonging to the same collection can have a different number of fields, and in turn, contain nested structures.

Horizontal scalability and high availability

Traditionally, relational DBs are quite complex to scale across multiple instances, ending up as a bottleneck or consuming many resources in an attempt to scale them vertically by increasing the capacity of a single machine. MongoDB solves this problem.

MongoDB allows you to distribute data across multiple machines using sharding, a form of horizontal scaling that facilitates high-productivity operations with large data sets. Instead of relying on a single high-speed, high-capacity server, MongoDB allows system administrators to increase capacity as required, even automatically, by simply defining how many machines can be correctly connected. In addition to horizontal scaling, MongoDB ensures high data availability. This is done through synchronising data between multiple servers (called replication) to have multiple copies of the data on different database servers.

The perfect DBMS doesn't exist

While we boast years of experience in relational DB design and management, we aren't qualified to offer consulting services in the most critical scenarios.

In many contexts, choosing a relational database is still the best option. However, some application scenarios exist where, due to the amount of data to be managed, its dynamism or heterogeneous and not easily 'defined' structure, the data can't be dealt with efficiently with relational DBs. At ELbuild, we select the best solution for data persistence scenario by scenario, frequently designing hybrid architectures. This is also thanks to the decomposition of applications into microservices. Find out how we can help you improve an existing application or design a new one.