When connecting to a SQL Server 2008 R2 from a .NET 4 client application on a different server in the same LAN, one can set three different network protocols:

  1. TCP
  2. Named Pipes
  3. Don't set anything in the connection string and use the default

What is best practice? What to choose?

Additional information: Both TCP and Named Pipes are enabled both on the server and on the client. The application is using database mirroring. Client and server communicate over a fast LAN.

We are investigating this because we have rare and spurious connectivity and timeout problems. (But regardless of that I'd like to know the best practice).

There is an article on this subject on MSDN but it is very generic and vague. It does not advise or recommend anything useful.

  • 2
    @ccook I believe it did. I also found tcp: configured as part of most connection strings in the environment of a different company years later. I assume they found similar problems.
    – usr
    Feb 17, 2017 at 14:19
  • 1
    I'm not confident enough to post that as an answer. It is weird, though, that such an egregious problem is unfixed. Must be very rare or hard to reproduce. @ccook
    – usr
    Feb 18, 2017 at 17:49
  • 1
    It's very infrequent and hard to reproduce for us. Fortunately when we created that app that spams connections concurrently every minute it can reproduce it every now and then. It's still very unpredictable. We're testing that change now though - waiting a while before calling it fixed. Having looked into this though, I'm definitely inclined to use tcp: by default unless the app and server are on the same machine.
    – ccook
    Feb 19, 2017 at 15:44
  • 1
    @ccook I had a new thought. Windows file shares are notoriously unreliable. Spurious errors and connection failures are seen by many. It's rare but hard/impossible to diagnose. When using named pipes you now pull this whole technology into your SQL Server deployment. That seems unwise on general grounds.
    – usr
    Feb 22, 2017 at 13:05
  • 1
    agreed. So far tcp: seems to be addressing the issue. We are waiting a bit to call it confirmed though.
    – ccook
    Mar 1, 2017 at 17:09

2 Answers 2


I prefer TCP/IP over Named Pipes, even though in most situations there will be no noticeable difference. You can do this by adjusting the protocols supported by the instance in SQL Server Configuration Manager rather than hard-coding things in your connection string (this makes it easier to make changes or to troubleshoot).

Essentially the routing and other overhead involved with named pipes (unless your apps are on the same machine as SQL Server, in which case there is only a little extra overhead) make it the less efficient option, especially at scale, in a slower network environment (100MB or less), or if your workloads come in bursts.

If your apps are on the same box as SQL Server, you should also keep shared memory in mind - if you have applications on the SQL Server box directly communicating with SQL Server, this is going to be the most efficient option.

You can read about the performance advantages of TCP/IP in more detail.

  • So it basically doesn't matter that much but it is generally preferable to go with TCP because there are no reasons to choose named pipes. Would you agree with that summary?
    – usr
    Sep 12, 2012 at 18:18
  • 1
    @usr Well, it matters when you scale, or if your network sucks. But yes, in general, there are no real benefits to choosing named pipes in any case, that I know of. Sep 12, 2012 at 18:30
  • Named pipes for a connection when client and database are on the same server/PC is quite normal I think. But in general, I too prefer TCP/IP and always for remote connections.
    – Zeek
    Sep 15, 2020 at 15:51

Named Pipes protocol are useful for the application that are designed around NetBIOS or other LAN-based protocols.

Named Pipes provides easy access to Remote Procedure Calls (RPC) within a single security domain and thus is advantageous to these applications.

Usually TCP Protocol is good in practice because you don't have to care about all these on the network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.