Browse the databases and collections stored on this server, inspect individual documents, narrow a collection with a filter and run aggregation pipelines against it.
What the Database Viewer is
The Database Viewer shows the databases this server stores, the collections inside each one, and the documents inside a collection. It is the page you open when you want to see what was actually written, rather than what a report says about it.
Access is role-based. Your permissions decide whether the Database Viewer is available to you at all, and which databases and collections you can read inside it. Where something is not yours to read, you get a Restricted access notice rather than an empty table.
It is a specialist tool, and it is rarely the fastest way to answer a product question. A count, a breakdown or a trend is a question for Drill, which is built for it and reads the same data. Come here when you need the stored document itself.
The address bar holds your query
The address bar is where the view lives. The database and the collection are path segments, and everything else you set is a query parameter: the filter, the fields to return, the sort field and its direction, the indexes view, and whichever document you have open. Copy the URL and you have handed a colleague the exact view on your screen. Refresh, and it comes back.
The project is part of the address too. It is the page's identity rather than one of its filters, so it survives every move inside the viewer: changing collection, opening the aggregation page, and coming back again. Land on the viewer with no project in the address and it adopts the project you used last, once, then writes it into the address so the project shown is always the project the URL names.
The query state deliberately does not survive a collection change. Moving to another collection clears the filter, the fields and the sort, because a query written against one collection's fields rarely means anything against another's. Switching between Data and Indexes clears them for the same reason.
Use Cases
Check what was actually stored
An SDK is sending something, and the numbers on a dashboard do not look the way you expected. Rather than reason about it from a report, read the stored document.
Pick the database and the collection, and the table lists its documents. Every row expands to the document's JSON, and rows are expanded by default, so a page of documents is readable without clicking anything. The search box matches on _id, which is the fast path when you already have an identifier from a log line or a support ticket.
While you are looking at a collection, the view refreshes itself every ten seconds, so a document being written right now appears without a reload. That polling pauses whenever the browser tab is hidden or a dialog is open, and your manual expansions survive a refresh.
Narrow a collection to a few documents
A collection with millions of documents is not something you read. You narrow it until what is left is small enough to look at.
Three controls do that, and they combine. The filter query is a MongoDB query document, written as JSON or assembled from condition chips. Fields to return is a projection: pick a handful of fields and they stop being buried inside the expanded JSON and become real columns in the table, which is what makes a page of documents comparable down a column. Sort orders the result by one field, ascending or descending.
Once anything is active, a strip above the table says Filter is applied and spells out the query, the fields and the sort that produced what you are looking at, with one control to clear all of it. That strip matters more than it looks: a filtered table and an empty collection look identical otherwise.
Summarize a collection without exporting it
Sometimes what you need is not a document but a figure computed over many of them.
The Aggregation action opens a page where you write a MongoDB aggregation pipeline against the collection you were browsing and run it. Results come back as a table in the same shape as the browser's, rows expandable to their JSON.
Two things are worth knowing before you rely on it. Some pipeline stages need global admin rights, and when you are not a global admin those stages are stripped out and the page warns you which ones, so a pipeline can run and answer a narrower question than the one you wrote. And a pipeline the server judges too slow to hold a request open is moved to background processing, at which point it keeps running whether or not you stay on the page.
FAQs
Can I edit or delete a document here?
No. The viewer browses and queries; it does not offer editing or deleting from any of its screens.
Why can I see fewer databases or collections than a colleague?
Because permissions are set per person, so you and a colleague can open the same page and be offered different databases and collections.
Where did my filter go when I switched collection?
It was cleared on purpose. Filters, fields and sort are written against a specific collection's fields, so they are dropped when you move to another one, and when you switch between Data and Indexes.
Can I share what I am looking at?
Yes. Everything that defines the view is in the URL, including the project scope and, on the aggregation page, the pipeline. Send the address.
Does the table update on its own?
Yes, every ten seconds while the tab is visible and no dialog is open, on the MongoDB databases. ClickHouse is never polled.
Why is the Builder tab greyed out?
Because the query currently in the Code tab uses syntax the condition chips cannot represent. The query is fine and will run; it just cannot be shown as chips. Edit it as code.