A slow first write does not automatically mean the INSERT is poorly tuned. The first request may also pay for application startup, authentication, creation of a connection pool, query compilation, data-page reads, or storage and transaction-log warm-up.
Last updated: October 13, 2026.
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
INSERT dbo.WriteProbe (Payload, CreatedAt)
VALUES (N'warm-up-test', SYSUTCDATETIME());
ROLLBACK TRANSACTION;
SET STATISTICS TIME OFF;
SET STATISTICS IO OFF;Run a probe only against a dedicated test table in a safe environment. Execute it several times in the same session, then repeat with a new connection. This separates SQL execution from connection-opening overhead.
Measure each boundary independently
Microsoft documents SET STATISTICS IO for logical and physical I/O. Pair it with SET STATISTICS TIME to see server-side parse, compile, and execution time. If SQL reports a few milliseconds while the application reports seconds, investigate outside the statement.
Log timestamps immediately before opening the connection, after Open, before executing, and after completion. Test the first connection after process startup, the next command on the same connection, and a later command after returning the connection to its pool.
Check pooling and storage before changing the query
The Microsoft ADO.NET connection pooling documentation explains that the first open creates a pool and later opens can reuse physical connections. Slightly different connection strings, credentials, or databases create separate pools and can make supposedly repeated requests behave like first requests.
Repeat the test after an application restart and after a long idle period. Record DNS, TLS, login, and command durations separately, and compare the application clock with the SQL Server measurements. This reveals whether the delay belongs to process initialization, the network path, connection establishment, or statement execution.
When server time is genuinely high only on the first execution, inspect the actual execution plan, waits, data-file reads, and transaction-log write latency. Do not hide a storage or DNS problem by adding an arbitrary warm-up write. Continue with Query Store plan inspection, faster batch inserts, and SQL Server plan variants.
