By prepending a collection’s name with its containing database, you can get a fully qualified collection name called a namespace. For instance, if you are using the blog.posts collection in the cms database, the namespace of that collection would be cms.blog.posts. Namespaces are limited to 121 bytes in length and, in practice, should be less than 100 bytes long.

In addition to grouping documents by collection, MongoDB groups collections into databases. A single instance of MongoDB can host several databases, each of which can be thought of as completely independent. A database has its own permissions, and each database is stored in separate files on disk. A good rule of thumb is to store all data for a single application in the same database. Separate databases are useful when storing data for several application or users on the same MongoDB server.

Because any document can be put into any collection, the question often arises: “Why do we need separate collections at
all?” It’s a good question—with no need for separate schemas for different kinds of documents, why should we use more than one collection? There are several good reasons:
• Keeping different kinds of documents in the same collection can be a nightmare
for developers and admins. Developers need to make sure that each query is only
returning documents of a certain kind or that the application code performing a
query can handle documents of different shapes. If we’re querying for blog posts,
it’s a hassle to weed out documents containing author data.
• It is much faster to get a list of collections than to extract a list of the types in a
collection. For example, if we had a type key in the collection that said whether
each document was a “skim,” “whole,” or “chunky monkey” document, it would
be much slower to find those three values in a single collection than to have three
separate collections and query for their names (see “Subcollections”
on page 8).
• Grouping documents of the same kind together in the same collection allows for
data locality. Getting several blog posts from a collection containing only posts will
likely require fewer disk seeks than getting the same posts from a collection containing
posts and author data.
• We begin to impose some structure on our documents when we create indexes.
(This is especially true in the case of unique indexes.) These indexes are defined
per collection. By putting only documents of a single type into the same collection,
we can index our collections more efficiently.

Collections are schema-free. This means that the documents within a single collection can have any number of different “shapes.” For example, both of the following documents could be stored in a single collection:
{«greeting»: «Hello, world!»}
{«foo»: 5}

A collection is a group of documents. If a document is the MongoDB analog of a row in a relational database, then a collection can be thought of as the analog to a table.

MongoDB is type-sensitive and case-sensitive. For example, these documents are distinct:
{«foo»: 3}
{«foo»: «3»}
As are as these:
{«foo»: 3}
{«Foo»: 3}

Values in documents are not just “blobs.” They can be one of several different data types (or even an entire embedded document—see “Embedded Documents” on page 20).

Some features common to relational databases are not present in MongoDB, notably joins and complex multirow transactions. These are architectural decisions to allow for scalability, because both of those features are difficult to provide efficiently in a distributed system.