Essential MongoDB Administration Commands for Beginners

MongoDB administration starts in mongosh, but the goal is not to memorize every command. The goal is to know how to look around safely, confirm where you are, make small changes deliberately, and avoid destructive commands on the wrong database.

If you are new to MongoDB, practice these commands on a local instance or a disposable development database first. Some commands in this guide, such as dropDatabase() and drop(), permanently remove data. MongoDB will do what you ask; it will not know that you meant to run the command somewhere else.

Connect with mongosh

For a local MongoDB instance on the default port, connect with:

mongosh

For a remote server, use a connection string supplied by your administrator or hosting provider:

mongosh "mongodb://[email protected]:27017/admin"

For TLS, replica sets, or MongoDB Atlas, the URI will include more options. Avoid pasting passwords into shell history when possible. Use prompts, environment-specific secret handling, or your platform’s credential tooling.

Once connected, check where you landed:

db

That prints the current database context. Many mistakes begin with assuming the shell is pointed at one database when it is pointed at another.

List and switch databases

Show visible databases:

show dbs

You may not see every database if your user lacks permissions. That is normal in secured environments.

Switch database context with use:

use myAppDB

MongoDB does not create the database immediately when you run use. It creates it when data is first written, such as when you insert a document or explicitly create a collection.

Check the current database again:

db

For scripts, prefer explicit database handles so the code is less dependent on shell context:

const appdb = db.getSiblingDB("myAppDB")
appdb.getCollectionNames()

Collections: list, create, inspect, remove

List collections in the current database:

show collections

Or use JavaScript:

db.getCollectionNames()

Create a collection explicitly when you need options such as validation, capped behavior, or clustered/index choices supported by your MongoDB version:

db.createCollection("logs")

Most application collections are created automatically on first insert, but explicit creation is clearer for administrative setup.

Inspect collection stats:

db.orders.stats()

See indexes:

db.orders.getIndexes()

Dropping a collection is destructive:

db.logs.drop()

Before running it in any shared environment, confirm the database and collection:

db
db.getCollectionNames()
db.logs.countDocuments({})

For very large collections, countDocuments({}) can be expensive. In that case, use metadata, sampling, or operational dashboards instead of running broad counts during peak traffic.

Insert a test document and query it

Even administrators need a few CRUD basics for verification. Insert a small document:

db.healthcheck.insertOne({ source: "admin-test", createdAt: new Date() })

Read it back:

db.healthcheck.find({ source: "admin-test" }).sort({ createdAt: -1 }).limit(5)

Remove only the test document:

db.healthcheck.deleteMany({ source: "admin-test" })

Use specific filters. Avoid broad deletes while learning. A command like deleteMany({}) removes every document in the collection.

User administration basics

User commands run against the database where the user is defined. Administrative users are often created in admin. Application users may be created in the application database, depending on your security model.

Switch to admin:

use admin

Create an administrative user with a prompted password:

db.createUser({
  user: "appAdmin",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

For a normal application, use narrower permissions. For example, an app that only reads and writes myAppDB should not receive broad admin roles:

use myAppDB

db.createUser({
  user: "myAppUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myAppDB" }
  ]
})

List users in the current database:

show users

Update roles carefully:

db.grantRolesToUser("myAppUser", [ { role: "read", db: "reporting" } ])

Remove roles just as deliberately:

db.revokeRolesFromUser("myAppUser", [ { role: "read", db: "reporting" } ])

The safest habit is least privilege: give the user only the database and role needed for the job.

Server status and current operations

serverStatus returns a large document with counters and runtime information:

db.serverStatus()

Beginners usually do not need the whole document. Pull the sections you care about:

db.serverStatus().connections
db.serverStatus().mem
db.serverStatus().opcounters

Current operations can help when something is stuck or slow:

db.currentOp()

On a busy server, filter it:

db.currentOp({ active: true, secs_running: { $gte: 5 } })

Do not kill operations casually. If you need to terminate one, inspect it first and understand whether it is a user query, index build, backup, migration, or internal replication work.

Replica set checks

If your deployment is a replica set, these commands are common:

rs.status()
rs.conf()

rs.status() shows members, health, state, optime information, and which node is primary. Run it when applications report write failures, when a node has restarted, or when replication lag is suspected.

For a quick read preference sanity check, ask who the current node thinks it is:

db.hello()

Older examples may use isMaster(). Newer MongoDB versions support hello; you may still see the old command in existing scripts.

Dangerous commands deserve rituals

For destructive work, slow down. A simple ritual prevents real outages:

db
show collections
// confirm hostname or connection string in your terminal prompt or notes
// confirm backup or restore plan if this is production
db.collectionName.drop()

For database removal:

use databaseToRemove
db.dropDatabase()

That command drops the current database. The danger is not the syntax; the danger is being in the wrong context.

A beginner-friendly admin checklist

When you connect to a MongoDB environment, get used to this sequence:

db
show dbs
use myAppDB
show collections
db.orders.getIndexes()
db.serverStatus().connections
db.currentOp({ active: true })

Those commands tell you where you are, what exists, whether basic access works, and whether anything obvious is happening right now.

MongoDB administration becomes much less intimidating when you treat mongosh as an inspection tool first and a change tool second. Look, confirm, then act. Use narrow roles, prompted passwords, filtered queries, and explicit database names. That habit matters more than memorizing a long list of commands.

Read database and collection sizes carefully

Beginners often use show dbs as a sizing tool, but it is only a starting point. Storage engines, compression, indexes, and deleted space can make size numbers surprising. Use collection stats when you need more detail:

db.orders.stats()

Look at index size too:

db.orders.totalIndexSize()

Indexes are not free. They speed up reads and some sorts, but every index adds write overhead and storage. If a collection has many indexes and writes are slow, list them and ask which queries actually use them:

db.orders.getIndexes()
db.orders.find({ customerId: "c123" }).explain("executionStats")

Do not drop indexes casually in production. An unused-looking index may support a monthly report or a rarely used admin screen. Check query logs, application owners, and monitoring before removing it.

Basic backup awareness

Command-line administration should always be connected to backup habits. Before destructive maintenance, know how the database is backed up and how restore has been tested. In self-managed MongoDB, you may see mongodump and mongorestore for logical backups:

mongodump --uri "mongodb://user@host:27017/myAppDB" --out ./backup

For large production systems, filesystem snapshots, cloud provider snapshots, Ops Manager, or Atlas backups may be more appropriate. The beginner-level point is simple: do not treat drop, deleteMany, or role changes as reversible unless you have a tested restore path.

A backup you have never restored is an assumption. Practice restoring into a non-production environment so you know the credentials, network access, and version compatibility before an incident.

Check logs when commands are not enough

mongosh shows server responses, but it does not replace logs. If users report slow queries, authentication failures, or connection churn, check MongoDB logs and your platform logs. In self-managed Linux deployments, logs may be under /var/log/mongodb/, depending on package and configuration. In containers, use the container runtime logs. In Atlas, use the Atlas UI and downloadable logs.

A common beginner mistake is to stare at serverStatus() while the real clue is an authentication failure, DNS problem, TLS mismatch, or application connection pool exhaustion in logs outside MongoDB.

Know the difference between database roles and operating system access

MongoDB users are not Linux users. Creating myAppUser in MongoDB does not create a shell account. Giving someone SSH access to a database server does not automatically give them database permissions, though it may give them dangerous indirect access if the server is poorly configured.

Keep those layers separate:

Linux user: controls access to the host and files
MongoDB user: controls database authentication and authorization
Network policy: controls who can reach the MongoDB port
TLS: protects traffic and can support certificate-based identity

A secure deployment needs all of them considered. A strong MongoDB password is not enough if the database listens publicly without firewall rules. A private network is not enough if every application uses an admin role.

A safer habit for production shells

When working in production, make the prompt and connection obvious. Some teams use terminal colors, shell aliases, or read-only users for inspection. At minimum, run a few identity checks after connecting:

db.runCommand({ connectionStatus: 1 })
db
db.hello()

connectionStatus shows authenticated users and roles. db shows context. hello gives topology information. Those three checks prevent a surprising number of mistakes.

For routine inspection, use a read-only account. Switch to a privileged account only for the specific change window. That small friction is useful. It forces you to notice when you are about to do something that can change data.

When to stop and ask for help

Some MongoDB commands are beginner-friendly; some are not. Be cautious with replica set reconfiguration, sharding metadata, forced reconfigs, killing operations, compacting collections, and changing authentication settings on a live system. Those actions can affect availability.

If the command changes cluster topology or removes data, pause and get a second review. The best administrators are not the ones who type fastest. They are the ones who know when a command deserves a backup, a maintenance window, and another set of eyes.

Understand read concern and write concern at a high level

Beginners do not need to tune read and write concern on day one, but they should know these settings exist. Write concern controls the acknowledgement MongoDB gives after a write. A stronger write concern can wait for replication to more members. A weaker one may return sooner but gives less assurance about durability across failures.

Read concern controls what level of data consistency a read asks for. In many simple applications the defaults are fine, but in replica sets and distributed systems, these settings influence what your application can safely assume after failover or during replication lag.

The administrative lesson is practical: when someone reports “MongoDB lost a write” or “the app read stale data,” do not look only at the insert command. Check the driver settings, write concern, read preference, read concern, replica set health, and application retry behavior.

Be careful with examples copied from the internet

MongoDB syntax has changed over time. Older blog posts may use the legacy mongo shell instead of mongosh, old helper names, or commands that still work but are no longer preferred. Some examples also run with authentication disabled, which is not a safe production assumption.

When copying a command, ask three questions:

Which MongoDB version was this written for?
Which database context does it run in?
What permissions does the connected user need?

If the command is destructive, add a fourth question: how do I restore if this goes wrong?

Use Compass and Atlas without abandoning the shell

Graphical tools are useful. MongoDB Compass can help inspect documents, indexes, and query plans. Atlas provides monitoring, backups, alerts, and user management for hosted clusters. Those tools are often easier for visual inspection than raw shell output.

Still, learn the shell commands. During incidents, automation, SSH-only environments, or documentation reviews, a precise mongosh command is easier to share than “click the third tab in the UI.” The best workflow is not shell versus GUI. Use the GUI to explore and the shell to express repeatable actions clearly.