How MongoDB Scales Global, Multi-Cloud Observability on VictoriaMetrics Enterprise

As MongoDB grows, its observability platform grows in tandem—a multi-cloud metrics platform serving global engineers, on-premises and self-managed.

TL;DR

MongoDB, the data platform trusted by more than 67,000 customers, runs its global observability on VictoriaMetrics Enterprise—self-managed, on its own infrastructure, across AWS, Google Cloud and Azure.

• The problem: growth. New services, new regions, and a widening multi-cloud footprint pushed telemetry volumes up faster than the existing tooling could scale.
• What they evaluated: extending current tooling with query-bridging layers, building a bespoke orchestration layer, and other industry alternatives.
• Why VictoriaMetrics won: one platform that delivered all of it—fast queries at scale, a native global view across clouds and regions, full Prometheus/PromQL compatibility, and a self-managed architecture that MongoDB controls.
• The architecture: vminsert, vmstorage, vmselect, and vmalert scale independently on Kubernetes via the VM Operator. vmagent collects metrics. Data stays in its local region; engineers query globally.
• The migration: evolution, not rip-and-replace. Grafana dashboards, alerting rules, recording rules, and exporters carried over unchanged.
• The result: sub-second queries at global scale (p50 < 10ms, p90 < 100ms), operated by fewer than 10 engineers for hundreds of internal users across dozens of teams—with no Thanos query bridging required.
• What’s next: multi-tenancy, and VictoriaLogs to extend the same architecture into log management.

Trusted by more than 67,000 customers globally to power modern applications and AI, MongoDB is the world’s leading data platform. From major financial institutions and healthcare providers to automotive manufacturers and AI leaders—including Barclays, Toyota, Novo Nordisk and ElevenLabs—organizations rely on MongoDB to power their most critical applications and AI initiatives.

As the company’s global footprint and product portfolio continued to grow across multiple cloud providers and regions, the demands on its observability infrastructure grew too. To provide engineers with reliable visibility at increasing scale, MongoDB invested in an observability platform built for its increasing scale. Today, VictoriaMetrics Enterprise gives MongoDB engineers a unified view of platform health and performance across a multi-cloud, multi-region environment, while remaining fully self-managed and under MongoDB’s control.

Supporting MongoDB’s growth meant keeping pace with an increasingly complex operating environment. As MongoDB expanded, new services, additional regions, and a growing multi-cloud footprint drove a sharp increase in telemetry volumes and observability demands. The team needed a platform that could scale alongside the business—ingesting ever-larger volumes of data without compromising query performance, while providing engineers with a unified view across cloud providers and regions, even as data remained local to each environment. After evaluating options, including extending its existing tooling with query-bridging layers, building a bespoke orchestration layer, and other industry alternatives, MongoDB chose VictoriaMetrics Enterprise as it offered the greatest scalability and flexibility for the years ahead.

MongoDB’s lengthy evaluation reflected the complexity of its growing platform. Each option offered clear strengths, but none delivered everything the team needed. What set VictoriaMetrics Enterprise apart was its ability to meet MongoDB’s full set of requirements in a single platform: fast query performance at scale, a native global view across clouds and regions, seamless compatibility with the Prometheus ecosystem, and a resilient, fully self-managed architecture that kept the platform under MongoDB’s control. Just as importantly, Prometheus compatibility allowed the team to retain its existing dashboards, alerts, and operational workflows while adopting a platform built to support the next stage of growth.

That scalability begins with a modular architecture designed to adapt to changing demand. Rather than scaling the platform as a single unit, VictoriaMetrics separates ingestion, storage, querying, and alerting into independently scalable components. vminsert handles ingestion, vmstorage persists data, vmselect serves queries, and vmalert evaluates alerting rules. As workloads change, MongoDB can scale only the components under pressure, maintaining predictable performance without overprovisioning the rest of the platform.

MongoDB manages the deployment on Kubernetes using the VM Operator, while vmagent collects metrics across environments. Data remains within its local region for operational efficiency and governance. At the same time, engineers can query across regions and cloud providers through a single global view—providing consistent visibility without moving raw telemetry around the world.

Just as important as the architecture was the ease of adoption. Rather than replacing existing tooling and retraining engineering teams, MongoDB was able to build on the observability practices already in place. Grafana dashboards, alerting rules, recording rules, and exporters all carried over unchanged because VictoriaMetrics natively supports PromQL and the broader Prometheus ecosystem. Metric collection is consolidated onto vmagent, which reads existing scrape configurations directly, allowing engineers to continue working with familiar tools while benefiting from significantly greater scalability.

“Everything we do starts with our customers. As MongoDB has continued to grow, we needed an observability platform that could grow with us—Victoria Metrics is remarkably scalable and easy to use, allowing our engineers to move quickly, delivering value for our internal engineering teams, and our customers. ,” said persephone thorn, Manager Observability at MongoDB. “VictoriaMetrics Enterprise has given us the visibility and flexibility to operate a globally distributed platform with confidence. We were able to build on the tools and workflows our engineers already knew, while gaining the scalability and query performance we needed to support our next stage of growth and continue delivering the experience our customers expect.”

When issues arise, vmalert continuously evaluates alerting rules and, through Alertmanager, routes notifications to the on-call engineers via the team’s existing channels, including Slack and mobile alerts. The platform’s global view lets teams investigate incidents spanning multiple regions and cloud providers from a single query, dramatically simplifying troubleshooting.

Today, MongoDB has an observability platform built to scale with its rapidly growing global business. Engineers can monitor an increasingly complex, globally distributed environment through a unified view across cloud providers and regions, while maintaining the fast query performance and operational consistency needed to troubleshoot issues quickly and confidently. By preserving existing workflows and adopting an architecture that scales each component independently, the team has expanded observability without increasing operational complexity, providing a resilient foundation that can continue to support MongoDB’s growth for years to come.

Looking ahead, the team is now exploring multi-tenancy to further simplify global observability through a single-query view across environments, while also evaluating VictoriaLogs to extend the same independently scalable architecture beyond metrics and into log management.

Three VictoriaMetrics Enterprise capabilities drove the upgrade.

• Security and compliance. Business support and security SLAs help MongoDB satisfy auditors and meet increasingly stringent compliance demands—the kind of requirements that grow right alongside the business.
• Data management at scale. Downsampling and roll-ups let the team keep long-horizon historical data affordably—essential for capacity planning in a growth environment—with multi-tenant statistics and limits on their roadmap.
• Automated backups. Operational insurance for a platform hundreds of engineers depend on daily.

Throughout, MongoDB valued direct access to the engineers behind VictoriaMetrics for straight technical answers. The team views VictoriaMetrics Enterprise and the open-source core as complementary: the same battle-tested engine, with the capabilities and support a platform this critical calls for.

If your company is growing, your telemetry is growing faster. Teams whose observability needs are scaling with their business can run a VictoriaMetrics cluster that separates ingestion, storage, query, and alerting, keeps full Prometheus compatibility, and runs on-prem under your control. The same dashboards and alerts carry over—the migration is evolution, not rip-and-replace.

“The scraping and storage components of VictoriaMetrics are rock solid. They scale to very high numbers of ingested metrics, Daily Active Timeseries, and high label cardinality. They also handle reasonable bursts in the amount of exported metrics, allowing us to easily handle changes in the underlying metrics workloads.” -Philip Wernersbach, Site Reliability Engineer

MongoDB’s story is the pattern, not the exception: pick the observability platform with room to grow, and growth stops being a platform problem.

• 100s of engineers served internally
• 100s of millions metric samples ingested per minute
• 3 clouds AWS, Google Cloud & Azure—one global view
• 90% queries complete under a second.

A VictoriaMetrics cluster in which ingestion, storage, querying, and alerting each scale independently—capacity is added exactly where growth demands it, and performance stays predictable as usage climbs.

• Unified global view across multiple cloud providers and regions: data stored locally, queried globally—removing the need for Thanos query bridging.
• Operated by less than 10 engineers, serving a few hundred internal users across dozens of teams.
• Drop-in Prometheus compatibility—same dashboards and alerts retained; remaining legacy Prometheus migrating via vmagent.
• Enterprise capabilities—downsampling, automated backups, and security SLAs—that keep long-term data affordable and auditors satisfied.
• High-level metric ingestion rates that reflect MongoDB’s growth: 10’s millions of log entries per minute

MongoDB uses VictoriaMetrics Enterprise as its metrics observability platform. It runs self-managed on MongoDB’s own infrastructure across AWS, Google Cloud, and Azure, giving engineers a single global view of platform health across every region and cloud provider.

MongoDB evaluated extending its existing tooling with query-bridging layers, building a bespoke orchestration layer, and other industry alternatives. Each had strengths, but only VictoriaMetrics Enterprise met the full requirement set in one platform: query performance at scale, a native global view, Prometheus compatibility, and a self-managed architecture MongoDB controls.

For MongoDB, yes. VictoriaMetrics provides a native local-store / global-query model, so telemetry stays in its own region while engineers query across regions and clouds from one place. That removed the need for a Thanos query-bridging layer between clusters.

No. VictoriaMetrics natively supports PromQL and the broader Prometheus ecosystem, so MongoDB kept its Grafana dashboards, alerting rules, recording rules, and exporters unchanged. vmagent reads existing Prometheus scrape configurations directly, so collection consolidates without rewriting configs.

Ingestion, storage, querying, and alerting are separate components—vminsert, vmstorage, vmselect, and vmalert. Each scales independently, so capacity is added only where load is growing. Performance stays predictable without overprovisioning the rest of the platform.

Metrics remain stored within their local region for operational efficiency and governance. Queries fan out across regions and cloud providers, so engineers get consistent global visibility without shipping raw telemetry around the world.

Fewer than 10 engineers operate the platform, serving a few hundred internal users across dozens of teams. Deployment is managed on Kubernetes using the VictoriaMetrics Operator.

vmalert continuously evaluates alerting rules and routes notifications through Alertmanager to on-call engineers on the channels the team already uses, including Slack and mobile alerts.

The same battle-tested engine, plus capabilities and support for business-critical platforms: business support and security SLAs for audit and compliance requirements, downsampling and roll-ups to keep long-horizon history affordable, and automated backups. Open source and Enterprise are complementary—Enterprise adds operational assurance on top of the same core.

Yes—VictoriaLogs applies the same independently scalable architecture to log management. MongoDB is evaluating it to extend observability beyond metrics.

Sub-second at global scale: p50 under 10ms and p90 under 100ms, with roughly 90% of queries completing in under a second.