What are the main performance differences between varchar and nvarchar SQL Server data types?

I'm working on a database for a small web app at my school using `SQL Server 2005`.
I see a couple of schools of thought on the issue of `varchar` vs `nvarchar`:

1. Use `varchar` unless you deal with a lot of internationalized data, then use `nvarchar`.
2. Just use `nvarchar` for everything.

I'm beginning to see the merits of view 2. I know that nvarchar does take up twice as much space, but that isn't necessarily a huge deal since this is only going to store data for a few hundred students. To me it seems like it would be easiest not to worry about it and just allow everything to use nvarchar. Or is there something I'm missing?

Always use nvarchar.

You may never need the double-byte characters for most applications. However, if you need to support double-byte languages and you only have single-byte support in your database schema it's really expensive to go back and modify throughout your application.

The cost of migrating one application from varchar to nvarchar will be much more than the little bit of extra disk space you'll use in most applications.

Since your application is small, there is essentially no appreciable cost increase to using nvarchar over varchar, and you save yourself potential headaches down the road if you have a need to store unicode data.

Be consistent! JOIN-ing a VARCHAR to NVARCHAR has a big performance hit.

nvarchar is going to have significant overhead in memory, storage, working set and indexing, so if the specs dictate that it really will **never** be necessary, don't bother.

I would not have a hard and fast "always nvarchar" rule because it can be a complete waste in many situations - particularly ETL from ASCII/EBCDIC or identifiers and code columns which are often keys and foreign keys.

On the other hand, there are plenty of cases of columns, where I would be sure to ask this question early and if I didn't get a hard and fast answer immediately, I would make the column nvarchar.

I deal with this question at work often:

- FTP feeds of inventory and pricing - Item descriptions and other text were in nvarchar when varchar worked fine. Converting these to varchar reduced file size almost in half and really helped with uploads.

- The above scenario worked fine until someone put a special character in the item description (maybe trademark, can't remember)

I still do not use nvarchar every time over varchar. If there is any doubt or potential for special characters, I use nvarchar. I find I use varchar mostly when I am in 100% control of what is populating the field.

For that last few years all of our projects have used NVARCHAR for everything, since all of these projects are multilingual. Imported data from external sources (e.g. an ASCII file, etc.) is up-converted to Unicode before being inserted into the database.

I've yet to encounter any performance-related issues from the larger indexes, etc. The indexes do use more memory, but memory is cheap.

Whether you use stored procedures or construct SQL on the fly ensure that all string constants are prefixed with N (e.g. SET @foo = N'Hello world.';) so the constant is also Unicode. This avoids any string type conversion at runtime.

YMMV.

Why, in all this discussion, has there been no mention of UTF-8? Being able to store the full unicode span of characters does not mean one has to always allocate two-bytes-per-character (or "code point" to use the UNICODE term). All of ASCII is UTF-8. Does SQL Server check for VARCHAR() fields that the text is strict ASCII (i.e. top byte bit zero)? I would hope not.

If then you want to store unicode *and* want compatibility with older ASCII-only applications, I would think using VARCHAR() and UTF-8 would be the magic bullet: It only uses more space when it needs to.

For those of you unfamiliar with UTF-8, might I recommend [a primer][1].


[1]:

[To see links please register here]

Generally speaking; Start out with the most expensive datatype that has the least constraints. **Put it in production**. If performance starts to be an issue, find out what's actually being stored in those `nvarchar` columns. Is there any characters in there that wouldn't fit into `varchar`? If not, switch to varchar. Don't try to pre-optimize before you know where the pain is. My guess is that **the choice between nvarchar/varchar is not what's going to slow down your application** in the foreseable future. There will be other parts of the application where performance tuning will give you much more *bang for the bucks*.

Disk space is not the issue... but memory and performance will be.
Double the page reads, double index size, strange LIKE and = constant behaviour etc

Do you need to store Chinese etc script? Yes or no...

And from MS BOL "[Storage and Performance Effects of Unicode][2]"

**Edit**:

Recent SO question highlighting how bad nvarchar performance can be...

[SQL Server uses high CPU when searching inside nvarchar strings][3]


[2]:

[To see links please register here]

[3]:

[To see links please register here]