Sometimes one MongoDB aggregation needs to return more than one result.
For example, from the same payments collection, you may want revenue by payment method, total revenue, and the latest paid payments.
You could write separate aggregations for each one. But $facet lets you keep them in the same pipeline.
It takes the same input documents and sends them through smaller pipelines. Each one returns its own result.
That is why $facet is useful for dashboards, reports, filters, and analytics pages.
MongoDB describes $facet as a way to run multiple aggregation pipelines in one stage on the same input documents. You can read more in the official MongoDB documentation.
The Payments Example
For this example, we will use a payments collection.onA document may look like this:
{
amount: 120,
method: "card",
currency: "USD",
status: "paid",
paidAt: "2026-05-20T10:30:00Z"
}
Let’s say you want a small report on paid payments.
You need revenue by payment method, total revenue, and the latest paid payments.
All of these answers come from the same collection.
That is where $facet helps. You start with one filtered set of payments, then split it into different results.
In VisuaLeaf, this is easier to follow because you can see the data first, then build the pipeline step by step.
Build the Pipeline Visually
Now, we can build the aggregation step by step.
The first stage is $match.
{
$match: {
status: "paid"
}
}
This keeps only paid payments.
It is better to filter the data before $facet, because every branch will use the same clean input.
In VisuaLeaf, you can see this directly in the preview. After the $match stage, the output should show only documents where status is paid.
Add the $facet Stage
After filtering the payments, we can add $facet.
This is the part where the pipeline splits.
Until now, the aggregation had one path. With $facet, the same paid payments can go in a few different directions.
For this example, I created three sections inside $facet: byMethod, revenueSummary, and latestPayments.
They all start from the same filtered payments. They just answer different questions.
1. byMethod
The first one is byMethod.
Here, the payments are grouped by $method.
So instead of looking at every payment one by one, we can see how each payment method performed.
For example, card payments may have one total, bank transfers another total, and PayPal another one.
This branch also counts how many payments each method has.
2. revenueSummary
The next one is revenueSummary.
This is the quick summary of the paid payments.
It gives the total revenue, the number of payments, and the average payment amount.
After the values are calculated, $project keeps the result clean. We do not need every internal field here. We only need the numbers that will be shown in the report.
3. latestPayments
The last one is latestPayments.
This branch is for the recent records.
It sorts the paid payments by paidAt, with the newest payments first. Then it keeps only a few results.
That makes it useful for a small table, like “latest payments” in a dashboard.
Check the Final Result
After the branches are ready, run the aggregation.
The result will look different from a normal list of documents.
Instead of getting only payments, you get one result with separate sections inside it.
{
byMethod: [...],
revenueSummary: [...],
latestPayments: [...]
}
Each section comes from one branch inside $facet.
byMethod shows the grouped revenue by payment method.
revenueSummary shows the main numbers.
latestPayments shows the newest paid records.
This is why $facet works well for reports. You can prepare several parts of the same page from one aggregation.
Check the Generated Query Code
After building the pipeline visually, you can open the generated query code.
This is useful because you can see the exact MongoDB aggregation behind the visual steps.
In this example, the query looks like this:
db.payments.aggregate([
{
$match: {
status: "paid"
}
},
{
$facet: {
byMethod: [
{
$group: {
_id: "$method",
totalPayments: { $sum: 1 },
totalAmount: { $sum: "$amount" }
}
},
{
$sort: {
totalAmount: -1
}
}
],
revenueSummary: [
{
$group: {
_id: null,
totalRevenue: { $sum: "$amount" },
numberOfPayments: { $sum: 1 },
averagePayment: { $avg: "$amount" }
}
},
{
$project: {
_id: 0,
totalRevenue: 1,
numberOfPayments: 1,
averagePayment: { $round: ["$averagePayment", 2] }
}
}
],
latestPayments: [
{
$sort: {
paidAt: -1
}
},
{
$limit: 5
},
{
$project: {
_id: 0,
amount: 1,
method: 1,
currency: 1,
paidAt: 1
}
}
]
}
}
])
This makes the visual builder easier to trust. You are not locked into a hidden workflow. You can build the pipeline visually, then read, copy, or adjust the generated code when you need it.
When This Is Useful
$facet makes sense when several results come from the same filtered data.
In this example, everything starts with paid payments.
From there, we get payment method totals, a revenue summary, and the latest payments.
That is the kind of structure you often need in a dashboard or report.
You do not need $facet for every aggregation. If you only need one result, a normal pipeline is easier.
But when the same data needs to answer a few different questions, $facet keeps the logic in one place.
Conclusion
$facet looks a little strange at first, but the idea is not hard.
You start with one set of documents, then split that data into different results.
In this example, we started with paid payments. From there, we got revenue by method, a revenue summary, and the latest payments.
That is why $facet is useful for reports and dashboards. You can prepare several parts of the same page from one aggregation.
And when you build it visually, it is much easier to see what each branch is doing.
You can also try this in VisuaLeaf if you want to see the pipeline step by step instead of reading only the code.
Top comments (1)
Wow, nice explanation. It's easier to understand how $facet works when you can see it visually.