The three commands to list databases in mongosh are show dbs for the quick view, db.adminCommand({ listDatabases: 1 }) for the full output with sizes, and show collections for the collections in the current database. The reason “mongo list dbs” is still a top search is that show dbs only shows the databases the current user can read, and the empty list after connecting is almost always an authentication problem, not a “no databases exist” problem. The empty list is the trap that wastes the most time.
This post is the three commands, the output each one produces, and the one diagnostic that catches the auth case.
Table of contents
- The direct answer: three commands, three questions
show dbs: the quick listlistDatabases: the full output with sizesshow collections: what is inside one database- The empty-list problem: auth, not “no databases”
- The driver equivalent in Node, Python, and Go
- The hosted Mongo case: Atlas, DocumentDB, and self-managed
- FAQ
The direct answer: three commands, three questions
// 1. The quick list (mongosh shell helper, not a database command)
show dbs
// 2. The full output with sizes, total size, and warning if you're a partial user
db.adminCommand({ listDatabases: 1 })
// 3. The collections in the current database
show collections
The first is a mongosh shortcut. The second is the underlying admin command, with the same output plus sizes and a warning field. The third is for the current database, not the cluster.
show dbs: the quick list
Inside mongosh (the modern shell, formerly the legacy mongo shell):
test> show dbs
admin 132.00 KiB
config 12.00 KiB
local 40.00 KiB
myapp 48.00 MiB
reporting 72.00 MiB
The output is a table with three columns: the database name, the size on disk, and (in some mongosh versions) a blank column. The size includes the data and the indexes, and it is the same value the next command returns for the sizeOnDisk field.
The list is sorted by name, not by size. The order is the same regardless of the order you created the databases. The admin, config, and local databases are the three system databases; they exist in every MongoDB cluster, and you should not write to them.
The trap: show dbs only shows the databases the current user has access to. A user with no listDatabases privilege sees an empty list, even if the cluster has 50 databases. The empty list is the most common source of “where did my database go” reports.
listDatabases: the full output with sizes
For the full output, with sizes, total size, and the partial-warning field, use the admin command:
db.adminCommand({ listDatabases: 1 })
The output:
{
"databases": [
{ "name": "admin", "sizeOnDisk": 135168, "empty": false },
{ "name": "config", "sizeOnDisk": 12288, "empty": false },
{ "name": "local", "sizeOnDisk": 40960, "empty": false },
{ "name": "myapp", "sizeOnDisk": 50331648, "empty": false },
{ "name": "reporting", "sizeOnDisk": 75497472, "empty": false }
],
"totalSize": 130023040,
"totalSizeMb": 124,
"ok": 1
}
The fields:
name— the database name.sizeOnDisk— the on-disk size in bytes. Includes data and indexes. For WiredTiger (the default storage engine), this is the sum of all files for the database.empty— true if the database has no collections. (An empty database still appears in the list.)totalSizeandtotalSizeMb— the total across all returned databases. Useful for capacity planning.warning— present when the user has partial visibility. The text says “listing databases whose size is greater than 0…” and is the signal that the user is not seeing every database.
The warning field is the one to look for. If it is present, the user is missing some databases, and the fix is on the user side, not the database side. See the empty-list section below.
The command also accepts options:
// Filter by name pattern
db.adminCommand({ listDatabases: 1, filter: { name: /^myapp/ } })
// Include the database size
db.adminCommand({ listDatabases: 1, nameOnly: false })
// Just the names, no sizes
db.adminCommand({ listDatabases: 1, nameOnly: true })
The nameOnly: true form is faster for a large cluster, because the database does not have to compute the size. Use it when you are scripting and just need the list.
show collections: what is inside one database
For the collections in the current database:
test> use myapp
myapp> show collections
users
sessions
orders
The output is one collection per line, with no metadata. For more detail:
// List collections with size and document count
db.getCollectionInfos()
// Just the names
db.getCollectionNames()
// With size only
db.runCommand({ listCollections: 1 })
The getCollectionInfos() form is the modern equivalent of show collections with metadata, and it is the form the drivers use. The output includes the collection name, the type (collection, view, timeseries), the options (capped, validator, storage engine config), and the index info.
The interesting use: db.getCollectionInfos({ name: "users" }) returns just the one collection’s info, which is the right way to confirm a collection exists and inspect its schema validator without a full list.
The empty-list problem: auth, not “no databases”
The most common “show dbs returns nothing” report. The cluster has 50 databases. The user is authenticated. The output is empty. The cause is almost always one of three things.
The user is not authenticated. db.runCommand({ connectionStatus: 1 }) shows the auth state. If authInfo.authenticatedUsers is empty, the user is not authenticated. Reconnect with the right credentials, or check the connection string.
The user has no listDatabases privilege. Even if authenticated, a user with read access to one database only sees that one (and not always — listDatabases requires the explicit privilege on the cluster). The fix is to grant the right privilege:
// Grant listDatabases to a user
db.grantRolesToUser("app_user", [{ role: "readAnyDatabase", db: "admin" }])
For an application user that should not have listDatabases (which is the right default for least-privilege), the application should not call show dbs at all. The application knows its database name; it should connect to that database directly, not enumerate the cluster.
The user is in a partial-visibility state. Some MongoDB drivers and the legacy shell show only the databases the user has been granted access to, and add a warning. The mongosh shell shows the warning in the warning field of listDatabases. The fix is the same as the previous case.
For a hosted MongoDB (Atlas, DocumentDB, a self-managed cluster), the authentication model is the same. The empty-list is almost always one of these three. The diagnostic is the same db.runCommand({ connectionStatus: 1 }).
The driver equivalent in Node, Python, and Go
For application code, the equivalent of show dbs is a listDatabases call through the driver. The shape:
Node (mongodb driver):
const { MongoClient } = require('mongodb');
const client = new MongoClient(uri);
await client.connect();
const admin = client.db('admin');
const { databases } = await admin.command({ listDatabases: 1 });
console.log(databases);
await client.close();
Python (pymongo):
from pymongo import MongoClient
client = MongoClient(uri)
databases = client.list_databases()
for db in databases:
print(db['name'], db.get('sizeOnDisk', 0))
Go (mongo-go-driver):
client, _ := mongo.Connect(ctx, options.Client().ApplyURI(uri))
databases, _ := client.ListDatabases(ctx, bson.D{})
for _, db := range databases {
fmt.Println(db.Name, db.SizeOnDisk)
}
All three return the same shape (a list of documents with name and sizeOnDisk), and the nameOnly and filter options work the same way. The application code should use these for the same reasons as the shell: discover databases, audit the cluster, or build a tool that lists databases.
The trap: a connection-pooled driver in a long-lived application does not usually need to call listDatabases. The application knows the database name. The call is for tooling, migrations, or one-off audits.
The hosted Mongo case: Atlas, DocumentDB, and self-managed
For MongoDB Atlas, the experience is the same. The show dbs command works against the Atlas connection string, the listDatabases command returns the same shape, and the auth model is the same. The Atlas UI is a friendlier surface for the same data, with the cluster’s databases listed by name, size, and shard count.
For Amazon DocumentDB (the AWS-managed Mongo-compatible service), the show dbs and listDatabases commands work, but DocumentDB is a different engine under the hood (a modified Postgres, not MongoDB). The output may be missing some fields (sizeOnDisk is approximate), and the auth model is the same as RDS, not the same as MongoDB.
For a self-managed MongoDB cluster (the most common production case), the same commands work, and the auth model is whatever the deployment was configured with. The empty-list problem is more common in self-managed setups, where the access controls are less standardized.
For a hosted equivalent where the database is part of the platform, the MCP server pattern extends to a database tool that gives AI agents scoped access to the database without exposing the entire cluster. The same pattern works for non-AI tooling: a small service that the application calls to fetch the data it needs, with the service doing the audit logging.
How this fits the rest of the stack
A managed MongoDB instance is also a hosting cost — the cluster size, the storage, the bandwidth, and the connection count each show up as a separate line item. The team’s mental model for the database cost is the sum of those numbers, and the team should know the total before adding the next collection or the next replica. The RunxBuild hosting calculator is the right place to model that — pick the MongoDB tier, the storage, the connection count, and the replica count, and the calculator shows what the database costs at the team’s actual usage.
Useful related references:
FAQ
How do I list all databases in MongoDB?
In mongosh: show dbs. For the full output with sizes: db.adminCommand({ listDatabases: 1 }). The latter returns a JSON document with the databases array, total size, and a warning field if the user has partial visibility.
Why is show dbs returning an empty list?
Most often, the user is not authenticated, or the user has no listDatabases privilege. The diagnostic is db.runCommand({ connectionStatus: 1 }) — if authInfo.authenticatedUsers is empty, reconnect. If authenticated, grant the right role with db.grantRolesToUser("user", [{ role: "readAnyDatabase", db: "admin" }]).
How do I see the size of every database?
db.adminCommand({ listDatabases: 1 }) returns the sizeOnDisk for each database and the totalSize for the cluster. The sizes include data and indexes.
How do I list collections in a database?
In mongosh: show collections (or show tables as an alias). For more detail: db.getCollectionInfos(). The output includes the collection name, type, options, and index info.
Can I list databases from a Node.js app?
Yes. Use client.db('admin').command({ listDatabases: 1 }) to get the list with sizes, or client.db('admin').command({ listDatabases: 1, nameOnly: true }) to get just the names. The pymongo equivalent is client.list_databases(); the mongo-go-driver equivalent is client.ListDatabases(ctx, bson.D{}).
What is the difference between show dbs and listDatabases?
show dbs is a mongosh shell helper that calls listDatabases under the hood and formats the output as a table. listDatabases is the admin command, with the full JSON output. The nameOnly and filter options are only available on the command, not on the shell helper.