Introduction

MultipleActiveResultSets=True, usually called MARS, lets one SQL Server connection keep more than one active result set open at the same time. That sounds similar to opening multiple connections, but the tradeoff is different: MARS is a convenience feature on one connection, while multiple pooled connections are the normal way to run truly independent database work.

What MARS Actually Changes

Without MARS, a single SqlConnection typically cannot keep one SqlDataReader open and then execute another command on that same connection. With MARS enabled, that pattern becomes possible.

A connection string looks like this:

var connectionString =
    "Server=.;Database=AppDb;Integrated Security=true;MultipleActiveResultSets=True";

That allows code such as:

1using var connection = new SqlConnection(connectionString);
2connection.Open();
3
4using var customers = new SqlCommand("SELECT Id FROM Customers", connection);
5using var reader = customers.ExecuteReader();
6
7while (reader.Read())
8{
9    var id = reader.GetInt32(0);
10
11    using var orders = new SqlCommand(
12        "SELECT COUNT(*) FROM Orders WHERE CustomerId = @id",
13        connection);
14
15    orders.Parameters.AddWithValue("@id", id);
16    var count = (int)orders.ExecuteScalar();
17    Console.WriteLine($"{id}: {count}");
18}

That code is convenient, but convenience is not the same thing as throughput.

What MARS Does Not Mean

MARS does not turn one connection into several fully independent channels with free parallelism. The operations still share one underlying connection context and all the semantics that come with it.

So if the real goal is independent work, concurrency, or simpler transaction boundaries, multiple connections are often the better model.

Why Multiple Connections Are Often the Default

ADO.NET uses connection pooling. That means opening and closing short-lived logical connections is usually much cheaper than people fear.

1using var connection1 = new SqlConnection(connectionString);
2using var connection2 = new SqlConnection(connectionString);
3
4connection1.Open();
5connection2.Open();

In most application scenarios, those Open() calls reuse pooled physical connections rather than paying the full handshake cost every time.

That makes multiple connections a very normal solution when:

• operations are independent,
• separate transactions make sense,
• the code is easier to reason about,
• or different tasks may run concurrently.

Often the Best Answer Is Neither

If you reached this decision because your code executes one query inside a loop over another query, step back. The biggest performance problem may be the query pattern itself rather than whether you use MARS or two connections.

This loop:

1while (reader.Read())
2{
3    // run another SQL query here
4}

often wants to become a single set-based SQL query instead.

1const string sql = @"
2SELECT c.Id, COUNT(o.Id) AS OrderCount
3FROM Customers c
4LEFT JOIN Orders o ON o.CustomerId = c.Id
5GROUP BY c.Id";
6
7using var connection = new SqlConnection(connectionString);
8connection.Open();
9using var command = new SqlCommand(sql, connection);
10using var reader = command.ExecuteReader();
11
12while (reader.Read())
13{
14    Console.WriteLine($"{reader.GetInt32(0)}: {reader.GetInt32(1)}");
15}

That removes the nested round trips entirely and is often better than either MARS or extra connections.

When MARS Is Reasonable

MARS is reasonable when:

• you are maintaining legacy code built around nested readers,
• refactoring query structure is expensive,
• and actual measured performance is good enough.

It can also be helpful when you want to simplify application code without opening another connection for a small amount of overlapping work.

But it should be a deliberate choice, not a blanket default.

When Multiple Connections Are Cleaner

Multiple connections are usually cleaner when:

• different operations should not share one connection context,
• separate transaction scopes are important,
• one task should not wait on the read state of another,
• or your code is easier to understand when each unit of work owns its own connection.

Because pooling is standard, this approach is often simpler than developers expect.

Think About Transactions and Debugging

MARS can make behavior more subtle because several commands are now flowing through one logical connection. That can complicate debugging and make transaction behavior harder to reason about compared with one connection per unit of work.

Simplicity has value. If two separate connections express the design more clearly, that is often the better choice unless measurement proves otherwise.

Common Pitfalls

The biggest pitfall is assuming MARS is a performance feature first. It is mostly a convenience feature for certain access patterns.

Another mistake is avoiding multiple connections because of old fears about connection cost. In pooled ADO.NET applications, that fear is often outdated.

Developers also frequently miss the bigger issue: nested queries inside loops. A better SQL query often beats both MARS and multi-connection juggling.

Finally, do not choose based on guesswork. If the code path is important, measure it under realistic load instead of relying on intuition.

Summary

• MARS allows multiple active result sets on one SQL Server connection.
• It is mainly about convenience, not free parallel execution.
• Multiple pooled connections are usually the cleaner default for independent work.
• Before choosing either one, ask whether the real fix is a better set-based SQL query.
• Use MARS deliberately when it simplifies code and the measured behavior is acceptable.