The correct MAXDOP setting for most SQL Server instances in 2026 is not zero. For servers with up to 8 logical processors, set MAXDOP to the number of logical processors. For servers with more than 8 logical processors, set MAXDOP to 8 as a starting baseline, then adjust based on your NUMA topology and workload. Microsoft's official guidance, updated in 2019 and still current, recommends this approach. Leaving MAXDOP at the default of 0 allows SQL Server to use every available processor for a single query, which causes parallelism-related blocking and CPU contention in most production environments.

What Is MAXDOP and Why Does the Default Cause Problems?

MAXDOP stands for Maximum Degree of Parallelism. It controls how many CPU threads SQL Server can use to execute a single query in parallel. The server-level setting lives in sys.configurations, but it can be overridden at the database level (SQL Server 2016 and later) and at the query level using a hint.

The default value of 0 means no limit. On a 32-core server, SQL Server can theoretically spin up 32 threads for a single query. That sounds fast, but it creates real problems in practice.

Parallel queries compete for a synchronisation object called a CXPACKET wait. When one thread finishes its portion of work before others, it sits idle waiting. The more threads involved, the more waiting. You end up with queries that look busy but are actually spending a significant portion of their execution time in thread synchronisation overhead. On busy OLTP systems, this compounds quickly.

There's also the scheduler contention issue. Each parallel thread needs a worker thread. On a server handling hundreds of concurrent sessions, allowing unrestricted parallelism means a handful of large queries can consume all available worker threads, starving smaller queries of the CPU time they need.

How to Check Your Current MAXDOP Configuration

Before changing anything, establish your baseline. Run this against your instance:

-- Check server-level MAXDOP
SELECT name, value, value_in_use, description
FROM sys.configurations
WHERE name = 'max degree of parallelism';

-- Check database-level MAXDOP overrides (SQL Server 2016+)
SELECT name, max_dop
FROM sys.databases
WHERE max_dop <> 0;

-- Check your NUMA topology
SELECT COUNT(DISTINCT memory_node_id) AS numa_nodes,
       COUNT(*) AS total_schedulers
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE';

This gives you three critical pieces of information: what the server thinks MAXDOP is, whether any individual databases override it, and how many NUMA nodes you're working with. A sql server performance audit should always start here.

If you're seeing high CXPACKET or CXCONSUMER waits in your top wait statistics, a misconfigured MAXDOP is almost certainly contributing. Run this to check:

SELECT TOP 10
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    CAST(wait_time_ms * 1.0 / waiting_tasks_count AS DECIMAL(10,2)) AS avg_wait_ms
FROM sys.dm_os_wait_stats
WHERE wait_type IN ('CXPACKET', 'CXCONSUMER', 'CXSYNC_PORT', 'CXSYNC_CONSUMER')
ORDER BY wait_time_ms DESC;

What Is the Right MAXDOP Value for Your Server?

There's no single universal answer, but Microsoft's guidance gives you a solid framework. Here's how to apply it in practice.

Step 1: Count your logical processors and NUMA nodes. Use the query above to identify your NUMA topology. A NUMA node is a grouping of CPUs with their own local memory. Queries that cross NUMA boundaries pay a latency penalty.

Step 2: Apply the baseline formula.

  • Fewer than 8 logical processors: set MAXDOP to the number of logical processors.
  • 8 or more logical processors, single NUMA node: set MAXDOP to 8.
  • 8 or more logical processors, multiple NUMA nodes: set MAXDOP to the number of logical processors per NUMA node, capped at 8.

Step 3: Adjust for workload type.

  • OLTP workloads with high concurrency: consider MAXDOP values of 2 to 4. Parallelism helps less here, and the contention cost is higher.
  • Reporting or data warehouse workloads: higher MAXDOP values (8 to 16 or beyond) are often appropriate because queries are large, concurrent sessions are fewer, and parallelism genuinely reduces wall-clock time.
  • Mixed workloads: start at 8 and monitor. Adjust based on wait statistics over two to four weeks.

Step 4: Apply the change.

-- Set server-level MAXDOP (requires 'show advanced options' enabled)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'max degree of parallelism', 8;
RECONFIGURE;

-- Set database-level MAXDOP (SQL Server 2016+)
ALTER DATABASE YourDatabaseName
SET MAXDOP = 4;

The database-level setting overrides the server-level setting for that specific database. This is particularly useful when you have a mixed environment where one database needs aggressive parallelism and another needs tight limits.

What About Cost Threshold for Parallelism?

MAXDOP doesn't work in isolation. SQL Server also uses the "cost threshold for parallelism" setting to decide whether a query is even eligible to go parallel. The default is 5, which is absurdly low. It was calibrated against hardware from the mid-1990s.

On modern hardware, a query with an estimated cost of 5 is trivial. Allowing those queries to go parallel is wasteful. Most experienced DBAs raise this to somewhere between 25 and 50 as a starting point.

-- Check current cost threshold
SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'cost threshold for parallelism';

-- Raise it to 50 (adjust based on your environment)
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;

Raising the cost threshold means fewer queries go parallel, which reduces CXPACKET waits and frees up worker threads for concurrent sessions. Combined with a sensible MAXDOP, this change alone can produce measurable throughput improvements on busy OLTP systems.

How Does DOP Feedback Change the Picture in SQL Server 2022?

SQL Server 2022 introduced Degree of Parallelism (DOP) Feedback as part of the Intelligent Query Processing feature set. When enabled under database compatibility level 160, the query processor can automatically reduce the DOP for individual queries that show inefficient parallelism patterns.

This doesn't replace manual MAXDOP configuration. DOP Feedback works within the boundaries you set. It can reduce DOP below your MAXDOP setting, but it cannot exceed it. Think of your MAXDOP configuration as the ceiling, and DOP Feedback as an intelligent mechanism operating below that ceiling.

DOP Feedback is enabled by default when you're on compatibility level 160 and the Query Store is active. You can verify its activity through Query Store reports or by querying sys.query_store_plan_feedback.

For environments still on SQL Server 2019 or earlier, DOP Feedback is not available, and manual tuning of MAXDOP and cost threshold remains the primary lever.

Key Takeaways

  • Never leave MAXDOP at 0 on a production server. The default allows unlimited parallelism, which causes CXPACKET contention and worker thread exhaustion on busy systems.
  • The Microsoft-recommended baseline is MAXDOP 8 for servers with 8 or more logical processors, adjusted down to the logical processor count per NUMA node if that number is lower than 8.
  • Raise cost threshold for parallelism from 5 to at least 25 to 50. This prevents trivial queries from going parallel unnecessarily and is one of the highest-value, lowest-risk changes you can make.
  • Use database-level MAXDOP overrides (SQL Server 2016 and later) to apply different parallelism limits to different workloads on the same instance without affecting other databases.
  • SQL Server 2022's DOP Feedback can automatically tune parallelism per query, but it operates within your configured MAXDOP ceiling, so correct baseline configuration still matters.

What to Do Next

MAXDOP misconfiguration is one of the most common findings in a sql server health check, but it's rarely the only one. In our experience conducting sql health check engagements across Australian organisations, the majority of SQL Server instances have at least three to five configuration issues that are actively affecting performance or reliability.

A DBA Services sql server health check service covers MAXDOP, cost threshold for parallelism, memory configuration, tempdb layout, backup integrity, index fragmentation, and dozens of other settings that compound over time. We deliver a written report with prioritised, actionable recommendations, not a generic checklist.

If your SQL Server environment hasn't had an independent review in the past 12 months, it's worth doing before a performance problem forces the conversation. Our dba support services team works with organisations across Australia on both one-off health checks and ongoing managed database support.

Contact DBA Services to arrange a sql server health check and get a clear picture of where your instances stand.