SqlQueryStress: a SQL Server load simulator with SSMS session settings

What the tool is for

The repository is a SQL query stress simulator, and the README credits its origin: it was created by Adam Machanic, with a link to the source code announcement on his site. The fork maintained here adds a command line front end and a modern runtime, and the repository is licensed MIT with the last push on 2026-10-09.

The use case is narrow and specific: you have a query, a stored procedure or an index design that behaves differently under concurrency than it does when you run it once, and you want to put load on it deliberately and watch what the server does. The linked article, Tune SQL Server Databases, Stored Procedures, and Indexes with SqlQueryStress, and the wiki both frame it that way, as a tool for tuning rather than for general load testing of an application.

The scale of the thing is worth noticing. The release tags are numbered 0.9.8.102, 0.9.8.88 and 0.9.8.77, with the newest from 2026-08-20, so the build number is part of the version and the project is still iterating within the same minor version. The topic tags are performance, sql-server and stress-test, which is the whole scope in three words.

The audience is a database professional on Windows, someone with a query plan they do not trust and a server they are afraid to disturb.

querysettings.sql decides the session your load runs in

This is the mechanism that makes the tool different from a loop of sqlcmd, and it is easy to miss because it is a file in the application directory rather than a setting in the interface.

The README states that SQL Query Stress automatically applies SQL Server connection settings similar to SQL Server Management Studio to ensure consistent query execution behavior, and that these settings are read from the querysettings.sql file located in the application directory.

The reason this matters is that a query's behaviour on SQL Server depends on session options as much as on the query. An option that changes the plan, the parallelism or the error behaviour can make a load test measure a different query from the one production runs. If your load generator opens connections with different options than your application does, the numbers it produces are about a query nobody runs.

The file is plain T-SQL and it is yours to edit. The README says any valid T-SQL SET commands can be added to it, and that they will be automatically executed when each connection is opened. That is the whole extension mechanism, and it is deliberately not a UI, because a load test session configuration is something you want to be able to copy into a repository, review in a diff and reproduce on another machine.

The note at the end of the section is the practical instruction: settings are applied automatically when connections are opened, so there is no need to modify your test queries. You change the session once, in one file, and every connection the tool opens inherits it.

The default SET block mirrors SSMS

The file that ships with the tool sets the options that Management Studio sets by default, and the README lists them:

SET QUOTED_IDENTIFIER ON;
SET ANSI_NULL_DFLT_ON ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET ANSI_NULLS ON;
SET ARITHABORT ON;
SET CONCAT_NULL_YIELDS_NULL ON;

The stated reason is consistency: these settings match the default SSMS configuration and ensure that query execution behavior is consistent between SSMS and SQL Query Stress.

Seven statements, and each one is a behaviour switch rather than a formatting preference. ARITHABORT in particular changes what happens on arithmetic overflow, and ANSI_WARNINGS and ANSI_NULLS affect a whole family of comparison and null handling results. If you have ever had a query that behaved differently in a script than in the management studio, this list is the shortlist of candidates.

The baseline therefore matches the tool people already trust, which is a deliberate conservative choice. It also means the tool inherits the SSMS defaults rather than the defaults of a bare connection, which is the right baseline for anyone whose production sessions were set up by a developer running the same commands in the same tool.

The one thing to check is whether your own production sessions match this list. If they set options the tool does not, the difference belongs in querysettings.sql.

Adding SET STATISTICS IO to see what the query actually reads

The README gives a short list of example customisations, and they show the intent:

SET NOCOUNT ON;
SET STATISTICS IO ON;
SET STATISTICS TIME ON;

NOCOUNT suppresses the row count messages that the client would otherwise receive for every statement, which is the usual first step in a script and matters here because the tool is measuring rather than displaying.

The other two are the interesting pair. STATISTICS IO turns on the reporting of logical and physical reads, and STATISTICS TIME turns on the timing information per statement, both of which come back as extra result sets. For a stress test, that is the difference between a wall clock number and an explanation of where the work went.

Because these are just SET commands in a file, the tool gives you the full T-SQL surface rather than a fixed set of checkboxes. If you want a specific trace or a particular option that changes the plan, you can set it the same way you would in any session, and it will apply to every connection the tool opens.

There is a practical caveat that follows from the mechanism. Since the file is read from the application directory, the settings belong to the installation, not to the project. Two people running the same stress test from two different installations can produce different results without doing anything wrong, so the file is worth keeping under version control alongside the queries you are testing.

sqlstresscmd runs the same engine from a terminal

The README points to a second front end in one sentence: a cross platform command line tool using the same load engine is also available, with a dedicated readme in the source tree at src/SqlQueryStressCLI/README.md.

The phrase that matters is the same load engine. The command line tool is not a separate implementation with its own characteristics, it is the same measurement machinery with a different interface. That makes the two front ends comparable in a way that two different tools would not be, because a result from one and a result from the other can be compared.

The difference in approach between them is where each one fits. The desktop application is a Windows tool, the README says it runs on any Windows machine with the .NET 10.0 runtime installed, and it is a graphical environment for a person who wants to watch a run and adjust it. The command line tool is cross platform and scriptable, which is what a pipeline or a repeatable experiment needs, and its own readme is the place to learn its options.

The split also explains the repository layout. The src/ directory holds the code, the docs/ directory holds the documentation, images/ holds the screenshot used in the README, and querysettings.sql sits at the repository root, which suggests the settings file is part of the distributed application rather than something generated at run time.

For a team, the practical arrangement is to use the desktop tool while investigating and the command line tool for anything that has to be repeatable, with the same querysettings.sql in both.

Where a stress simulator stops and a load test begins

The boundary of this tool is worth stating, because the name invites more than it delivers.

It is a query stress simulator. It puts concurrent load on a SQL Server instance and lets you watch what happens, in order to tune a query, a stored procedure or an index. The linked article makes that the purpose, and the tool's configuration surfaces point the same way, since the thing you configure is a session and a set of queries, not a user journey or a set of API calls.

So it is the wrong tool if you want to know how your application behaves under realistic traffic, because that involves the application, its connection pool, its ORM and its request mix, and none of those are what this program models. It is also the wrong tool if you want a general database benchmarking suite, since the point here is to reproduce a session context, not to compare engines.

There is a second practical limit that belongs in the same place. The tool applies the SSMS session defaults by default, and the settings live in the application directory. That is the right baseline for reproducing what a developer sees, and the wrong baseline for reproducing a production application that sets its own options. If your application's connection string or initialisation code sets session options, the file has to be edited to match, and if it does not, the load test is measuring a session configuration that does not exist in production.

That is also the reason the file is worth reviewing before the first run rather than after the first surprising result.

Editorial conclusion

Adopt SqlQueryStress if you need to reproduce the behaviour of a query under concurrent load on SQL Server and you care that the session context matches what Management Studio gives you, since a load test run with different SET options measures a different query. Do not adopt it as a general performance test suite, because it is a query stress simulator rather than a workload generator, and do not plan around the Windows desktop build if your pipeline is Linux, where sqlstresscmd is the option. Verify first that querysettings.sql in your installation directory holds the SET options your production sessions use, that you are on a release with the .NET 10.0 runtime available, and that your test database is a copy rather than the live one.

Frequently asked questions

Official sources

1. ErikEJ/SqlQueryStress on GitHub
2. Issues
3. License: MIT
4. README
5. Releases