Dissecting SolarWinds (Part Two): Legacy Architecture: The Challenge of Aligning with Modern Infrastructure

Before entering the discussion, it is necessary to emphasize that the goal of this series of articles is not to question the value or capability of the prominent IT infrastructure monitoring tools. Many of these solutions have been used in various organizations for years and play an important role in monitoring and managing IT environments. What is examined in this series of articles is more of an analytical look at some limitations and challenges that can become problematic for organizations. Therefore, if you intend to purchase SolarWinds software, we suggest that before making a decision, you also study the series of articles on dissecting SolarWinds.

If we look back, SolarWinds Orion was once considered one of the gold standards of network monitoring—a platform with a unified interface, relatively straightforward deployment, and a practical collection of tools for traditional IT teams. However, once we move beyond its user interface and visible features and examine its underlying layers, we encounter an architecture that, in many respects, was not designed for today's world. The challenge facing SolarWinds is not the result of a superficial flaw or a configuration mistake; rather, it is a direct consequence of architectural decisions made in a different era.

A Three-Tier Architecture That Appears Modern but Remains a Centralized Monolith

On the surface, SolarWinds presents itself as a three-tier architecture consisting of web, application, and database layers. In reality, however, this separation is largely logical rather than architectural.

The Orion Core—the central engine of the platform—maintains all modules within a structure characterized by a high degree of coupling, even with the presence of the SWIS API layer. Every extension, from Network Performance Monitor (NPM) to Server & Application Monitor (SAM) and Virtualization Manager (VMAN), stores its data and metadata within a shared schema and relies on fixed execution paths for even minor operations.

This means that, despite its multi-layer appearance, SolarWinds remains fundamentally an Orion monolith that cannot truly scale horizontally and instead becomes "larger" primarily by adding more Windows servers.

The Data Journey: An Old Production Line Rather Than a Modern Pipeline

To understand why SolarWinds encounters difficulties in large-scale or highly dynamic environments, it is enough to follow the path that data takes through the system.

Almost everything that is monitored—from data collected through SNMP and WMI to NetFlow—must pass through a polling cycle. Data first enters the Polling Engine, is then queued by the Job Engine, and ultimately all of this information is pushed toward a centralized SQL Server.

As a result, SolarWinds is predominantly a batch-based system rather than a streaming platform. Even in cases such as Syslog and SNMP Traps, which appear to operate in real time, data in many implementations still passes through SQL unless Log Analyzer has been fully integrated into the architecture.

This design may be suitable for environments consisting of a few hundred devices, but in today's infrastructures—where devices are highly dynamic, telemetry volumes have increased dramatically, and real-time responsiveness is expected—it effectively creates a significant bottleneck.

A single burst event in the network—for example, hundreds of containers being created and terminated or a sudden increase in NetFlow volume—can cause the Job Engine to fall behind. Although the Job Engine maintains multiple internal queues, it still relies on a common processing path and a shared dependency on SQL Server. The resulting delays propagate to the Polling Engine and ultimately to the database itself.

The outcome is predictable: data arrives later than expected, dashboards and graphs are not updated in a timely manner, and portions of network reality become temporarily invisible.

SQL Server: The Backbone and Simultaneously the Greatest Limitation

One of the defining characteristics of SolarWinds—or perhaps one of its most fundamental weaknesses—is that, in its on-premises deployment model, the majority of the platform's workload is concentrated on SQL Server.

The database simultaneously serves as:

• The primary datastore
• The transaction engine
• The historical archive
• A substantial part of the analytics backend

In modern architectures, these responsibilities are typically distributed across multiple services. In SolarWinds, however, they remain concentrated within a single component.

This is where many challenges begin.

In large environments, SQL Server must handle massive volumes of inserts, updates, and queries, resulting in table locking, slower write performance, increased read latency, and ultimately degraded console responsiveness.

Some jobs may even be forced to wait until database locks are released.

As data volumes grow, organizations are often pushed toward SQL Server Enterprise licensing, significantly increasing costs—not because of functional requirements, but because of architectural limitations.

Polling Engines: Scalability That Enlarges the Problem Instead of Solving It

Many organizations assume that adding additional Polling Engines will solve capacity issues.

The reality is more complicated.

In SolarWinds, a Polling Engine is not an independent collector. From both the data flow perspective and its dependency on SQL Server, it remains part of the same centralized architecture.

Consequently:

• More Polling Engines generate more SQL traffic.
• Coordination within the Orion Core becomes increasingly complex.
• The probability of operational issues rises.

In other words, SolarWinds scales with considerable complexity and, in many scenarios, simply becomes larger rather than more scalable.

Deep Dependence on the Microsoft Stack: Strength or Limitation?

SolarWinds is deeply dependent on the Microsoft ecosystem:

• IIS
• Windows Services
• SQL Server
• ASP.NET Web Forms

For organizations that have historically embraced a Windows-first strategy, this model may feel familiar and comfortable.

For modern infrastructures—where Kubernetes, Linux, containers, and multi-cloud environments have become standard—this dependence increasingly represents a limitation.

Deployment, upgrades, maintenance, backup procedures, and performance tuning all occur within a specific technological framework, and that framework effectively limits the adoption of many modern architectural patterns.

Although SolarWinds has attempted to address some of these challenges through Hybrid Cloud Observability, the core Orion platform still remains fundamentally dependent on its original architecture.

The Growing Gap Between SolarWinds' Design and Modern Distributed Networks

Ultimately, all of these issues point toward a single reality:

SolarWinds was designed for a world in which infrastructures were stable, networks were predictable, and data volumes were relatively modest.

It was an era in which a few five-minute polling cycles were sufficient to monitor an environment effectively.

Today's environments are fundamentally different.

Modern infrastructures experience:

• Thousands of endpoints appearing and disappearing every day.
• Massive and continuous telemetry streams.
• Requirements for real-time and distributed analytics.

In such a world, a centralized architecture built around a single database and batch-oriented processing increasingly struggles to keep pace.

Conclusion: SolarWinds Remains Useful, but Its Architecture Is Tied to the Past

SolarWinds continues to deliver acceptable performance in stable, traditional networks and within many medium-sized organizations.

However, when evaluated from an architectural perspective, it becomes clear that the platform faces structural limitations in distributed environments, cloud-based systems, and highly dynamic infrastructures.

The Orion Core monolith, complete dependence on SQL Server, the absence of distributed processing pipelines, and its polling-cycle-centric model all suggest that SolarWinds was designed for an era that no longer exists.

That is the central point of this article:

SolarWinds is not a broken platform; it is simply a product of a previous architectural generation. And this is a limitation that cannot be eliminated merely by adding more servers.

By contrast, platforms such as Moein Monitoring Platform, with their event-driven architectures and distributed storage models, represent examples of a newer generation of monitoring platforms—not necessarily better or worse in absolute terms, but more closely aligned with the data patterns and scale of today's networks.

Series of Articles on Dissecting SolarWinds