What is the difference between varchar and nvarchar?

Mainly **nvarchar** stores Unicode characters and **varchar** stores non-Unicode characters.

"Unicodes" means 16-bit character encoding scheme allowing characters from lots of other languages like Arabic, Hebrew, Chinese, Japanese, to be encoded in a single character set.

That means unicodes is using 2 bytes per character to store and nonunicodes uses only one byte per character to store. Which means unicodes need double capacity to store compared to non-unicodes.

I would say, it depends.

If you develop a desktop application, where the OS works in Unicode (like all current Windows systems) and language does natively support Unicode (default strings are Unicode, like in Java or C#), then go nvarchar.

If you develop a web application, where strings come in as UTF-8, and language is PHP, which still does not support Unicode natively (in versions 5.x), then varchar will probably be a better choice.

I always use nvarchar as it allows whatever I'm building to withstand pretty much any data I throw at it. My CMS system does Chinese by accident, because I used nvarchar. These days, any new applications shouldn't really be concerned with the amount of space required.

nvarchar stores data as Unicode, so, if you're going to store multilingual data (more than one language) in a data column you need the N variant.

I had a look at the answers and many seem to recommend to use `nvarchar` over `varchar`, because space is not a problem anymore, so there is no harm in enabling Unicode for little extra storage. Well, this is not always true when you want to apply an index over your column. SQL Server has a limit of 900 bytes on the size of the field you can index. So if you have a `varchar(900)` you can still index it, but not `varchar(901)`. With `nvarchar`, the number of characters is halved, so you can index up to `nvarchar(450)`. So if you are confident you don't need `nvarchar`, I don't recommend using it.

In general, in databases, I recommend sticking to the size you need, because you can always expand. For example, a colleague at work once thought that there is no harm in using `nvarchar(max)` for a column, as we have no problem with storage at all. Later on, when we tried to apply an index over this column, SQL Server rejected this. If, however, he started with even `varchar(5)`, we could have simply expanded it later to what we need without such a problem that will require us to do a field migration plan to fix this problem.

Although `NVARCHAR` stores Unicode, you should consider by the help of collation also you can use `VARCHAR` and save your data of your local languages.

Just imagine the following scenario.

The collation of your DB is Persian and you save a value like 'علی' (Persian writing of Ali) in the `VARCHAR(10)` datatype. There is no problem and the DBMS only uses three bytes to store it.

However, if you want to transfer your data to another database and see the correct result your destination database must have the same collation as the target which is Persian in this example.

If your target collation is different, you see some question marks(?) in the target database.

Finally, remember if you are using a huge database which is for usage of your local language, I would recommend to use location instead of using too many spaces.

I believe the design can be different. It depends on the environment you work on.

`nvarchar` is safe to use compared to `varchar` in order to make our code error free (type mismatching) because `nvarchar` allows unicode characters also.
When we use `where` condition in SQL Server query and if we are using `=` operator, it will throw error some times. Probable reason for this is our mapping column will be difined in `varchar`. If we defined it in `nvarchar` this problem my not happen. Still we stick to `varchar` and avoid this issue we better use `LIKE` key word rather than `=`.

Jeffrey L Whitledge with ~47000 reputation score recommends usage of nvarchar

Solomon Rutzky with with ~33200 reputation score recommends: Do NOT always use NVARCHAR. That is a very dangerous, and often costly, attitude / approach.

[To see links please register here]

[To see links please register here]

Both persons of such a high reputation, what does a learning sql server database developer choose?

There are many warnings in answers and comments about performance issues if you are not consistent in choices.

There are comments pro/con nvarchar for performance.

There are comments pro/con varchar for performance.

I have a particular requirement for a table with many hundreds of columns, which in itself is probably unusual ?

I'm choosing varchar to avoid going close to the 8060 byte table record size limit of SQL*server 2012.

Use of nvarchar, for me, goes over this 8060 byte limit.

I'm also thinking that I should match the data types of the related code tables to the data types of the primary central table.

I have seen use of varchar column at this place of work, South Australian Government, by previous experienced database developers, where the table row count is going to be several millions or more (and very few nvarchar columns, if any, in these very large tables), so perhaps the expected data row volumes becomes part of this decision.

`varchar` is used for `non-Unicode characters` only on the other hand `nvarchar` is used for both `unicode` and `non-unicode` characters. Some other difference between them is given bellow.

VARCHAR vs. NVARCHAR
--------------------

| | VARCHAR | NVARCHAR |
|:-:|:-:|:-:|
| Character Data Type | Variable-length, non-Unicode characters | Variable-length, both Unicode and non-Unicode characters such as Japanese, Korean, and Chinese. |
| Maximum Length | Up to `8,000 characters`| Up to `4,000 characters` |
| Character Size | Takes up `1 byte` per character | Takes up `2 bytes` per Unicode/Non-Unicode character |
| Storage Size | Actual Length (in bytes) | 2 times Actual Length (in bytes) |
| Usage | Used when data length is variable or variable length columns and if actual data is always way less than capacity | Due to storage only, used only if you need Unicode support such as the Japanese Kanji or Korean Hangul characters. |

The main difference between `Varchar(n)` and `nvarchar(n)` is:

[![enter image description here][1]][1]

`Varchar` ( Variable-length, non-Unicode character data) size is upto 8000.
1. It is a variable length data type
2. Used to store non-Unicode characters
3. Occupies 1 byte of space for each character

[![enter image description here][2]][2]

[1]:

[2]:

`Nvarchar`: Variable-length Unicode character data.

1. It is a variable-length data type
2. Used to store Unicode characters.
3. Data is stored in a Unicode encoding. Every
language is supported. (for example the languages Arabic, German,Hindi,etc and so on)