When installing SQL Server, one of the first screens you’ll see is the prerequisite check for memory and CPU cores. But those baselines only reflect the Database Engine itself. In reality, many deployments also add Replication, SSIS, SSRS, and SSAS on the same box. How should you size a server when all of these components are installed? Is there a single Microsoft guide that lists minimums for “everything on one server”? Or is it better to separate components by role?
Let’s go step by step—from novice to expert—so you know exactly how to plan.
Novice: Minimum vs. Recommended Resources
Microsoft publishes minimum and recommended requirements for the Database Engine, but not for every add-on. For the optional components, Microsoft gives performance/scaling guidance rather than strict minimums.
Here’s a consolidated baseline table (from Microsoft docs and industry practice):
| Component | Minimum CPU | Minimum Memory | Disk (install) | Notes |
|---|---|---|---|---|
| Database Engine | 1.4 GHz x64, 2 cores for production | 2 GB RAM | 6 GB | Official Microsoft minimums. |
| Replication (Distributor) | 2 cores | 4 GB RAM | Shared with DB Engine | Light footprint; separate server recommended for high volume. |
| SSIS (Integration Services) | 4 cores | 4–8 GB RAM (16 GB recommended) | <1 GB | ETL packages vary; in-memory transforms can consume tens of GB. |
| SSRS (Reporting Services) | 2 cores | 4 GB RAM (8–16 GB recommended) | 2 GB | Needs CPU for rendering, memory for caching. |
| SSAS (Analysis Services) | 2 cores | 4 GB RAM (scale RAM = 2–3× compressed model size) | 2 GB | Very memory dependent; separation from DB Engine recommended. |
⚠️ Important: These are bare minimums or realistic baselines to get the service installed and running. Production deployments should be sized higher based on workload.
Intermediate: Feature-by-Feature Impact
Each major feature has its own footprint:
- Replication: Light footprint on a dedicated Distributor. Scales with number of publications/subscriptions. (Replication Distribution Overview)
- SSIS: Memory-hungry for transformations. Scale Out available. (SSIS Scale Out)
- SSRS: Acts like a web service. CPU for rendering, RAM for caching. (SSRS Performance Guidance)
- SSAS: In-memory, requires RAM = 2–3× compressed model size. (SSAS sizing guidance)
Advanced: Consolidation vs. Separation
- All-in-one server: Simpler and cheaper, but risk of resource contention.
- Separation by role (recommended best practice):
- DB Engine: Isolated.
- Distributor: Dedicated if high-volume.
- SSIS: Separate if heavy ETL.
- SSRS: Separate if lots of reports/concurrent users.
- SSAS: Strongly recommended to isolate due to memory usage.
Memory & OS Considerations
SQL Server consumes all memory by default unless capped. Always:
- Leave 10–20% of RAM for the OS and monitoring tools.
- If SSIS or SSAS share the server:
- Reduce the DB Engine’s
max server memory. (Configure max server memory) - Reserve extra RAM for SSIS/SSAS workloads.
- Reduce the DB Engine’s
- Example: On 128 GB RAM → leave 12–16 GB for OS, 40 GB for SSAS (tabular model), 64 GB for DB Engine, 8 GB buffer for SSIS.
Practical Sizing Recommendations
- CPU: 8–16 cores for mid-tier consolidated servers; scale up with concurrency.
- Memory:
- DB Engine: 16–32 GB+ for production.
- SSIS: 8–16 GB baseline.
- SSRS: 4–8 GB.
- SSAS: 2–3× compressed model size.
- Always leave OS + feature buffers.
- Storage: SSD/NVMe for tempdb and staging; separate volumes for logs, data, backups.
Expert Notes
- Watch NUMA boundaries on big servers.
- Virtualization: pin cores/memory to avoid ballooning.
- HA: Availability Groups only protect the DB Engine—SSRS/SSAS need separate HA planning.
- Your approach (separate Distributor, separate SSRS) is exactly what Microsoft recommends.
Summary
- SQL Server installer minimums only cover the Database Engine.
- Add-on features (Replication, SSIS, SSRS, SSAS) don’t have hard Microsoft minimums—but baselines exist.
- Always leave 10–20% RAM for the OS, and cap the DB Engine memory if sharing with SSIS/SSAS.
- Consolidation is fine for dev/test; separation by role is best practice in production.
Final Thoughts
If you’re new, it’s tempting to put everything on one box. It works—but eventually SSIS packages, SSAS models, or SSRS reports will starve the Database Engine.
The right path is:
- Follow minimums as a floor, not a target.
- Leave memory for the OS and other features.
- Scale out to dedicated servers as workloads grow.
You’ve already separated the Distributor and SSRS — that’s excellent. For SSIS and SSAS, monitor usage closely and split them when contention appears.
References
- Microsoft Learn – Hardware and software requirements for SQL Server
- Microsoft Learn – Editions and Components of SQL Server
- Microsoft Learn – Replication Distribution
- Microsoft Learn – SSIS Scale Out
- Microsoft Learn – SSRS Performance and Scalability Guidance
- Microsoft Learn – SSAS sizing and configuration
- Microsoft Learn – Configure max server memory (SQL Server)
Discover more from SQLYARD
Subscribe to get the latest posts sent to your email.
