In our current project it just happens too often, that we need to extend columns by a couple of characters. From varchar(20) to varchar(30) and so on.

In reality, how much does it really matter? How good is this optimized? What is the impact of just allowing 100 or 200 or even 500 chars for normal "input" fields? An email can only have 320 chars, so ok - there is a good limit there. But what do I gain if I set it to 200, because I do not expect longer e-mail addresses than that.

Usually our tables will not have more than 100.000 rows, and up to 20 or 30 such columns.

We use SQL Server 2008 now, but it would be interesting to know how different DBs handle this issues.

In case the impact is very low - as I would expect, it would help to get some good arguments (backed up with links?) to convince my DBA, that this long-field-paranoia isn't really necessary.

In case it is, I'm here to learn :-)


7 Answers 7


The specific answer to your question (at least for Oracle and probably other databases) is that the length of the field doesn’t matter, only the length of the data. However, this shouldn’t be used as a determining factor concerning whether to set the field to its maximum allowable length or not. Here are some other issues you should consider before maxing out field sizes.

Formatting Any client tool that formats the data based on the size of the fields will require special formatting considerations. Oracle’s SQL*Plus for example by default displays the maximum size of Varchar2 columns even if the data is only one character long. Compare…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Bad Data Field length provides an additional mechanism to catch/prevent bad data. An interface shouldn’t attempt to insert 3000 characters into a 100 character field, but if that field is defined to be 4000 characters, it just might. The error woudn’t be caught at the data entry stage, but the system may have trouble further down when another application tries to process the data and chokes. As an example, if you later decide to index the field in Oracle you would exceed the maximum key length (depending on block size and concatenation). See…

create index i1 on f1(a);

Memory If the client application allocates memory using the maximum size, the application would allocate significantly more memory than is necessary. Special considerations would have to be done to avoid this.

Documentation The size of the field provides another data point of documentation about the data. We could call all tables t1, t2, t3, etc. and all fields f1, f2, f3, etc., but by specifying meaningful names we better understand the data. For example, if an address table for a company with customers in the U.S. has a field called State that is two characters we expect the two character state abbreviation to go in it. On the other hand if the field is one hundred characters we might expect the full state name to go in the field.

All that being said, it does seem prudent to be prepared for change. Just because all your product names today fit in 20 characters doesn’t mean they always will. Don’t go overboard and make it 1000, but do leave room for plausible expansion.


Here is a good starting point for you.


I may have misunderstood your original question. Let me see if I can find you a few other links for reference.

Here is good reference on data type selections: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Changing from varchar(20) to varchar(30) may seem like something small, but you need to understand more about how database structures work in order to be aware of the potential issues. For example, going to varchar(30) could push you past the tipping point of your columns (should all 30 bytes get used) being able to be stored on one page (less than 8060 bytes). This will lead to an increase in disk space used, a decrease in performance, and even some additional overhead with your transaction logs.

Here is a link for database structures: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Here is one for page splits and trx logging: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx



I thought I'd share another interesting point, which I found in a Stack Overflow question.

Original answer by: Nick Kavadias

A reason NOT to use max or text fields is that you cannot perform online index rebuilds i.e. REBUILD WITH ONLINE= ON even with SQL Server Enterprise Edition.

I would consider this to be a big disadvantage when adding n/varchar(max) columns arbitrarily, and according to the MS Site this restriction against doing online index rebuilds remains in SQL Server 2008, 2008 R2 and Denali; so it's not specific to SQL Server 2005.


In some cases, the amount of space you allocate for a varchar field will affect the amount of memory allocated for in-memory sorts.

I found the presentations at SQLWorkshops.com thought provoking, this presentation talks about a case where a sort for an order by is spilling over into tempdb because not enough memory is being allocated for char/varchar fields.


This webcast was also presented as an article at the following website:


Note in this presentation that the column being sorted on is not the char/varchar column, but the amount of space allocated for the varchar column in memory makes a difference in the query performance in some cases.



You end up with a lot of trailing whitespace...


It matters only related to disk space and character length. Of course search on char data types and indexes on these type of data will act slower than integer but this is another discussion.

Varchar data type is a "variable" data type so if you set up a limit of varchar (500) than this is the maximum character length for that field. Minimum length can be between 0 and 500. On the other hand the disk space claimed will be different for 10, 30 or 500 character fields.

I did sometimes a test for data type varchar (800) and for null values I had 17 bytes used, and for each character inserted it added one more byte. For example a 400 character string had 417 bytes used on the disk.


I don't think, that there is any difference between tables created with columns of varchar(20) or varchar((8000), as long the the actual max length is <= 20.

On the other side, in some cases giving the users the possibility to store longer strings might encourage them to do it.

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.