About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A small business application can run with its SQL Server database on the same Windows server, or with the database on a server of its own. Application vendors can support either layout, and on a hosted platform either can be built. The choice affects memory, licensing, security and how outages spread, so it is worth making on purpose.
Why it matters
One server is simpler and can be cheaper. Two servers separate the workloads and add hosting and administration costs. Whether they add Windows Server licensing cost depends on the licensing programme, edition, existing host rights and provider pricing. The wrong choice shows up later as slow performance, a licence bill that grew with the application, or an outage that took both parts down together.
How it works
Memory: SQL Server takes what it is allowed
SQL Server uses memory dynamically, and by default its limit is effectively uncapped. Microsoft states: It's recommended in all versions of SQL Server to configure an upper limit for SQL Server memory utilization by configuring the max server memory (MB).
On a shared server this matters more. Microsoft's method for setting the limit is to subtract, from total memory, what the operating system needs, memory SQL Server uses outside the limit, and other uses if the server is home to other applications that consume memory. Microsoft's recommended starting point is 75% of available memory not consumed by other processes.
So on a shared server, the application's memory has to be measured and reserved, and the database gets less. If the application's memory use grows, the SQL Server limit needs revisiting.
Processor: the application's cores may be licensed for SQL Server
When SQL Server is licensed per core for a VM, every virtual core in that VM counts. Microsoft's service provider terms state that The number of Licenses required equals the number of Virtual Cores in the Virtual OSE, subject to a minimum of four License per Virtual OSE.
On a combined server, the cores added for the application are SQL Server cores too. If the application needs four cores and the database four, a combined eight-core VM needs eight SQL Server core licences. Split into two four-core VMs, SQL Server needs four, and the application VM needs none. Which is cheaper depends on the SQL licensing model and edition, any additional Windows licensing cost, and the provider's VM price; work through the figures for the specific case. A second VM does not universally require another Windows licence: for example, Microsoft's service-provider Windows Server terms permit any number of operating system environments on a correctly licensed Datacenter host. Other programmes and editions have different rights. A separate article covers SQL Server licensing on VMs in more detail.
Processor contention also works the other way: a heavy report or index job can slow the application on the same server. MAXDOP controls the degree of parallelism and applies per task, not as a universal per-query CPU quota. Cost threshold for parallelism is the estimated serial-plan cost above which SQL Server considers parallel alternatives. Neither setting reserves cores for another program or caps every resource a query can consume.
Security: more running on one server
Microsoft's security guidance for SQL Server lists isolating services: Isolating services reduces the risk that one compromised service could be used to compromise others. It also advises not connecting SQL Server instances directly to the Internet, and dividing the network into zones separated by firewalls.
If the application server faces users or the Internet (a web front end, a remote desktop host, a file share), a combined server puts the database on the same machine as that exposure. A separate database server can sit behind a firewall that admits only the application server.
Outages and maintenance
On one server, a Windows update restart, a full disk or a fault takes the application and the database down together. Two servers do not make the application available while either is down, but they let each be patched, resized or restored on its own schedule, and a fault in one does not fill the other's disk or memory.
What to choose and why
| Situation | Leaning |
|---|---|
| Few users, light database, application on the same server is vendor-supported | One server, with a SQL Server memory limit and the application's memory measured |
| Application server faces users or the Internet directly | Two servers, with the database behind a firewall |
| Application needs several cores and SQL Server is licensed per core for the VM | Compare both designs' licence cost before deciding |
| Remote desktop users run the application on the server | Two servers; user sessions and the database compete for the same memory and processors |
| Growth expected, or reporting load planned | Two servers, so each can be sized separately |
What to measure before deciding
If the application already runs, measure it over a full business cycle, using the same Windows performance counters as for sizing:
- the application's own memory working set and processor time, separately from SQL Server's;
- SQL Server's memory use against its configured limit;
- disk latency on the volumes holding the database and its log;
- how many database round trips a typical user action makes, from the vendor or from a trace on a test copy.
The first two show whether the two workloads fit together. The last shows how sensitive the application would be to the database moving to another server.
Check the application vendor's documentation first. Some vendors require a separate database server above a number of users, or support only certain layouts.
Risks and limits
- Splitting adds network round trips. Applications that make many small database calls can slow down when the database moves to another server. Test with the real application on isolated test servers with synthetic data before deciding.
- Splitting adds a second server to patch, back up and monitor. Additional Windows licensing cost depends on the applicable rights and provider price; it is not automatic.
- Combining needs discipline. Without a SQL Server memory limit, SQL Server and the application compete for memory.
- Licensing figures here are illustrations. They are not licensing advice; confirm with the licence provider.
- No commands are given here. Microsoft's pages include configuration examples.
Sources
Opened 14 November 2026.
- Microsoft Learn: Server memory configuration options; displayed Last updated: 2026-05-11.
- Microsoft Learn: Security considerations for a SQL Server installation; displayed Last updated: 2026-06-23.
- Microsoft: Commercial Licensing Terms, SQL Server product entry.
Related service: Business solutions.
Related future topics
- SQL Server memory on a hosted VM.
- SQL Server licensing on virtual machines.
- Separating application tiers inside one hosted environment.
Learning notes
- SQL Server needs a memory limit on any server, and a lower one when it shares the server.
- Per-core SQL Server licensing counts every virtual core in the VM, including the application's.
- Microsoft's security guidance favours isolating services and keeping the database off the Internet.
- One server couples outages and maintenance; two servers separate them at extra cost.
- Test the split with the real application before committing.
This article was originally published on .