SonarQube Product Model, Editions, Components, and Architecture: Core Concepts and Mental Model

1. Current product snapshot

Chapter 01 established a governance chain around revision, rules, findings, New Code, and quality gates. Chapter 02 adds the systems model that tells you where each fact is produced and who owns it. On 2026-09-07 the free self-managed baseline is Community Build 26.9.0.129388. Commercial SonarQube Server is offered as Developer, Enterprise, and Data Center editions on 2026 Release 4.1; 2026.1.5 is the active LTA patch line. These are dated assumptions, not permanent constants.

2. Mental model: analysis is a chain of ownership

flowchart TD
A[Workspace / build / revision] --> B[Scanner]
B --> C[Index + analyzers + report]
C --> D[Report upload]
D --> E[Web/API acceptance]
E --> F[Compute Engine task]
F --> G[(Relational database)]
F --> H[(Search state)]
G --> I[Issues / measures / gate]
H --> I
I --> J[UI / Web API]
I --> K[CI / PR decoration]
L[SonarQube for IDE] -. developer feedback .-> A
L -. not the CI server task .-> I

The scanner executes in the developer/CI runtime and produces an analysis report. Upload acceptance is not final analysis. Server-side processing is asynchronous: the Compute Engine consumes a background task and creates durable project results. The database and search subsystem support persistent/queryable application state. The UI, Web API, and DevOps integrations consume that result. SonarQube for IDE is a separate developer-time feedback surface, which may synchronize configuration through connected mode but does not become the authoritative CI task simply because its findings look similar.

3. State stores you must not blur together

4. Product boundaries

Community Build is the free/open-source self-managed path and the mandatory lab baseline. SonarQube Server is self-managed commercial software with Developer, Enterprise, and Data Center editions. SonarQube Cloud is a hosted product whose service infrastructure is operated by Sonar; it is not a package you install beside Server. SonarQube for IDE runs in the developer environment and provides fast local feedback.

5. Web, Compute Engine, database, and search

The Web side serves UI/API traffic and accepts scanner reports. The Compute Engine processes queued analysis reports asynchronously. A relational database stores supported durable SonarQube application data. SonarQube also operates search state for fast query/navigation behavior. These responsibilities remain distinct even when a single-node deployment places them on one machine. Data Center Edition changes availability/scaling topology by introducing redundant application/search capacity; it does not change the meaning of a quality gate.

Do not treat the database or search index as application APIs. Supported administration happens through SonarQube configuration, UI/API, backups, and documented recovery procedures—not direct row/index edits.

6. Read-only architecture inventory

Before analysis, record: product and exact version; release or LTA stream; deployment package/image; scanner family/version/runtime; project key; endpoint; database choice as reported by supported system information; plugin inventory; configured DevOps integrations; and whether SonarQube for IDE is connected. Use fake/local values and authorized read-only views.

7. Common architecture mistakes

• Scanner = server: false; the scanner is a client-side analysis/report process.
• Upload = completed analysis: false; wait for the server-side background task.
• IDE = release gate: false; IDE feedback is not the authoritative CI/server analysis record.
• Cloud = hosted Server binary: too simplistic; Cloud is a separate managed product with different operational ownership.
• Search = editable external database: unsafe and unsupported as an application-level repair pattern.

8. Why this matters in DevOps

A release control is trustworthy only when the exact revision, effective scanner inputs, report/task identity, server result, policy context, and external delivery signal can be independently correlated. Architecture knowledge tells you where evidence lives and where a correction belongs.

Knowledge check

Official references and version notes

• SonarQube downloads and edition comparison — current Community Build, Developer, Enterprise, Data Center, and LTA identities.
• Community Build documentation — free self-managed baseline.
• SonarQube Server documentation — commercial Server behavior, operations, analysis, and integrations.
• SonarQube for IDE documentation — local analysis and connected mode.
• SonarQube Cloud documentation — hosted-product boundary.
• Release announcements — dated release cross-checks.