What is MongoDB?

MongoDB is a popular NoSQL document database — a database that stores data as flexible, JSON-like records instead of as rows in tables. “NoSQL” just means “not a traditional SQL/relational database” — it does not mean MongoDB has no query language (it has a rich one). MongoDB is a great fit when your data is shaped like nested objects, when your schema changes often, or when you need to scale writes across many servers. As a DevOps engineer you will install it, secure it, back it up, and connect apps to it — so it helps to understand the model before you run the commands.

The document model in plain English

In a relational database (like PostgreSQL or MySQL) you store data in tables made of rows and columns, and every row in a table must follow the same fixed shape (the “schema”). MongoDB throws that out and stores documents instead.

A document is a single record, written in a format that looks almost exactly like JSON (the text format { "key": "value" } used everywhere on the web). Documents are grouped into collections, which are roughly the MongoDB version of a table. A database holds many collections.

Here is a single user document:

{
  "_id": "65f1a2b3c4d5e6f7a8b9c0d1",
  "name": "Asha Patel",
  "email": "[email protected]",
  "roles": ["admin", "billing"],
  "address": {
    "city": "Mumbai",
    "country": "IN"
  },
  "createdAt": "2026-06-15T10:30:00Z"
}

Notice three things a relational table cannot do easily: the roles field is a list inside the record, the address field is a nested object inside the record, and there is no separate “addresses” table to join. The whole user — including their address and roles — lives in one document. Every document automatically gets a unique _id field that acts as its primary key.

What is BSON?

On disk and over the network, MongoDB does not store plain text JSON. It uses BSON (Binary JSON) — a compact binary version of JSON that is faster to read and supports more data types, such as dates, 64-bit integers, and raw binary data. You write and read documents as JSON; MongoDB stores them as BSON behind the scenes. You rarely deal with BSON directly.

When a flexible schema helps — and when it hurts

MongoDB is “schemaless” in the sense that two documents in the same collection can have different fields. This flexibility is its biggest strength and its biggest trap.

Situation	Use MongoDB?	Why
Data is naturally nested (orders with line items, a blog post with comments)	Yes	One document holds the whole object — no joins
Schema changes often during early development	Yes	Add a field to new documents without a migration
Catalogs where items have wildly different attributes	Yes	A book and a TV can live in one collection
Heavy reporting with many JOINs and aggregations across entities	Lean relational	SQL joins and constraints are built for this
Money, accounting, strict data integrity rules	Lean relational	Foreign keys and `NOT NULL` enforce correctness
You need multi-row transactions everywhere	Either	MongoDB supports transactions, but they are the exception, not the default

Gotcha: “Schemaless” does not mean “no rules”. If your app writes email in one place and emailAddress in another, MongoDB happily stores both and your queries silently miss data. Decide on a schema in your application code (or use MongoDB’s optional schema validation), even though the database will not force it on you.

MongoDB vs relational databases

Concept	Relational (PostgreSQL/MySQL)	MongoDB
Storage unit	Row in a table	Document in a collection
Schema	Fixed, enforced by the database	Flexible, enforced by your app
Relationships	Foreign keys + JOINs	Embed (nest) or reference by `_id`
Query language	SQL	MongoDB Query API (JSON-style)
Scaling out	Harder (read replicas, manual sharding)	Built-in sharding (splitting data across servers)
Best for	Structured, relational, transactional data	Nested, evolving, document-shaped data

How you will run it on Ubuntu

MongoDB runs as a normal systemd service on Ubuntu (Ubuntu 22.04/24.04 LTS). The server program is mongod (the “Mongo daemon”), and you talk to it with the modern shell mongosh. Once installed, the basic lifecycle commands look like this:

sudo systemctl status mongod
sudo systemctl enable --now mongod
mongosh

Output:

● mongod.service - MongoDB Database Server
     Loaded: loaded (/lib/systemd/system/mongod.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-06-15 10:31:02 UTC; 5s ago
   Main PID: 4821 (mongod)

By default mongod listens only on 127.0.0.1 (localhost) on port 27017 and starts with no authentication. That is fine for a first look on your own machine, but it is dangerous on a server — you must enable auth and a firewall before anyone else can reach it. The dedicated install and security pages walk through that step by step.

Useful Ubuntu paths to know:

Config file: /etc/mongod.conf
Data directory: /var/lib/mongodb
Log file: /var/log/mongodb/mongod.log

A quick licensing note (SSPL)

The free MongoDB Community Edition is licensed under the SSPL (Server Side Public License). For normal use — running it for your own app or company — SSPL behaves like a regular open-source license and costs nothing. The catch only matters if you want to offer MongoDB itself as a paid managed service to other people; in that case SSPL requires you to open-source large parts of your service stack. For 99% of DevOps work this never comes up, but it is why some Linux distributions do not ship MongoDB in their default repositories, so you install it from MongoDB’s own apt repository instead.

Best practices

Treat MongoDB as having a schema — define it in your application code even though the database does not enforce it.
Never run a production mongod without authentication and a firewall (ufw) restricting port 27017.
Embed data that is read together; use references (_id links) only when documents grow large or are shared.
Always add indexes for the fields you query and sort on — without them MongoDB scans every document.
Install from MongoDB’s official apt repository so you get security updates and a supported version.
Automate backups with mongodump on a schedule, and test that a restore actually works.