SQL Server hardware requirements start with the exact software version and edition. A server that passes Microsoft's installation checks can still miss a database's response-time or recovery targets. Before comparing processors and memory, ask the database owner to describe the work the system must complete, the busiest period it must handle and the evidence needed to accept a candidate.
This guide turns that information into a procurement brief. Your DBA and application owner should approve the workload, software rights and test results before the hardware specification becomes an order.
Fix the version, edition and deployment first
Write down the SQL Server major version, update level, edition, operating system and whether the instance will run on physical hardware or inside a virtual machine. Include the application supplier's supported combinations. An application approved for one release does not automatically become approved for another because the server is newer.
For SQL Server 2025 (17.x) on Windows, Microsoft's installation requirements specify an x64 processor, a 1.4 GHz minimum processor speed and at least 6 GB of available drive space. Minimum memory is 512 MB for Express and 1 GB for other editions. Those figures describe installation requirements, not an operational database specification. Check the edition-specific Windows support table and the requirements of every selected component.
Edition limits also affect the usefulness of extra hardware. Microsoft's SQL Server 2025 edition comparison limits a Standard Database Engine instance to the lesser of four sockets or 32 cores, with a 256 GB buffer-pool limit. Its note gives the earlier SQL Server 2022 Standard compute limit as four sockets or 24 cores. Do not copy limits between releases or treat the buffer-pool limit as a cap on all server memory use.
Have your licence owner review the chosen physical or virtual deployment against Microsoft's licensing guidance and the applicable agreement. SQL Server 2025 Developer editions are for development and testing, not production. Hardware rental alone does not establish SQL Server use rights.
Describe the work behind the connection count
A count of application users is only a starting point. Ask the DBA to separate open connections from requests actively doing work. Record the busy-hour transaction mix, scheduled imports, reporting queries and maintenance jobs. A short, frequent order lookup and a large reporting query create different demands even when both count as one request.
Use an agreed observation window that includes the real peak, such as month-end processing, rather than a quiet screenshot of CPU usage. Capture query response times, CPU demand, memory pressure and storage read/write latency through tools the DBA approves. Include failures and timeouts. Averages alone can conceal a slow transaction that regularly blocks a business process.
For a new application, request the supplier's workload assumptions and a representative test dataset. Mark unmeasured values as assumptions. Do not convert registered users, database file size or a processor brand into a claimed capacity without a workload test. If the instance will share a host, document the other workloads and their resource allocation too.
Complete a DBA-reviewed hardware worksheet
Copy this table into the request. Replace every blank with measured evidence, an explicit assumption or a decision owner. The physical server specification checklist covers the wider component and quotation brief; this worksheet adds the database-specific acceptance inputs.
| Input | What to record | Acceptance evidence and owner |
|---|---|---|
| Software boundary | SQL version, update, edition, OS and application support | DBA and application supplier approve the combination |
| Busy workload | Active requests, transaction mix, batch jobs and overlap window | Baseline capture or documented test assumptions |
| Response target | Named transactions, percentile, target time and test duration | Application owner signs the measurement method |
| Memory | Candidate RAM, other processes, other instances and proposed SQL allocation | DBA reviews memory pressure during the pilot |
| Data and growth | Current data/index sizes, growth horizon and retained test data | Database owner confirms the measurement date |
| Storage activity | Data, log, tempdb and backup locations; capacity and latency observations | DBA and storage owner review the busy-period trace |
| Recovery | Maximum acceptable data loss, restore deadline and backup destination | Recovery owner approves a witnessed restore test |
| Delivery decision | Exact candidate, test result, exceptions, licence approval and reviewers | Procurement receives a signed acceptance or rejection |
Keep the completed worksheet with the candidate specification. Record any later change to the database, virtual-machine allocation or storage layout so the acceptance result remains tied to the system actually tested.
Separate storage capacity from recovery readiness
Describe data, transaction logs, tempdb, retained backups and expected growth separately. A single total in terabytes does not explain which activity competes for storage during a busy period. Ask the storage owner to identify the actual devices or shared storage underneath the proposed volumes, including the effects of a virtual host.
Memory needs the same care. Microsoft's server memory guidance says to account for the operating system, allocations outside the configured SQL memory limit, other SQL instances and other applications. Let the DBA set and validate the allocation. Installed RAM and the instance's configured memory limit are different worksheet entries.
For recovery, state how much data loss is acceptable and how soon the application must return. Identify who provides backup storage, who runs restores and who validates the restored application. A successful backup job alone does not demonstrate that the full recovery deadline can be met. Include time to obtain the backup, restore it and complete the agreed application checks.
Accept a candidate through a controlled database pilot
Agree the test and pass conditions before comparing machines. Use an authorised, representative dataset with sensitive information handled under your organisation's rules. Keep the application build, SQL settings, data volume, workload mix and concurrency consistent between runs. Record storage and virtual-host details alongside the processor and RAM.
Run the named transactions and overlapping jobs for the agreed duration. Capture response-time percentiles, errors, resource observations and the recovery test result. Ask the DBA to distinguish a hardware constraint from query, indexing, locking or application behaviour before requesting a larger machine. Change one relevant factor at a time, then repeat the affected test.
Where SQL runs in a VM, add the guest allocations and host assumptions to the virtualisation requirements brief. The final decision should identify the exact accepted configuration, tested software versions, unresolved exceptions and owners. A pilot with incomplete recovery evidence should remain incomplete rather than becoming a general performance promise.
A hypothetical example of a useful brief
Imagine an order-processing application with 80 signed-in users, 20 actively submitting work at the expected peak, an overnight import and a daytime reporting job. These are illustrative assumptions, not a tested sizing rule or a C Prompt customer example.
The DBA would build a test around that transaction mix and decide whether the report must overlap with order entry. Procurement could then compare candidates against the same response and restore targets. The number 80 would remain a workload input, not a reason to declare a particular core count or RAM capacity sufficient.
Frequently asked questions
How much RAM does a SQL Server database need?
Use the actual workload, edition limits and competing memory needs to select a pilot candidate. Database size alone does not give a reliable RAM figure. Have the DBA review memory pressure and application response under the agreed workload before approving the capacity.
Are Microsoft's minimum requirements enough for production?
They establish an installation baseline for the documented version and platform. They do not establish your transaction throughput, response times or recovery capability. Production acceptance needs a representative database test and the application's supported software combination.
Does renting a server include a SQL Server licence?
Do not assume that it does. Ask for the hardware and software scope separately, and have the licence owner approve the applicable deployment rights. Any software entitlement must be confirmed expressly; Developer edition is not a production substitute.
Should the database always use the largest available processor?
Choose from workload evidence and the edition's usable capacity. More cores may not address a storage delay, blocking query or application bottleneck. Compare supported candidates under the same test, with licensing implications reviewed before the final hardware decision.