How long should SQL email fields be? [duplicate]

Answer 1

For email, regardless of the spec, I virtually always go with 512 (nvarchar). Names and surnames are similar.

Really, you need to look at how much you care about having a little extra data. For me, mostly, it's not a worry, so I'll err on the conservative side. But if you've decided, through logically and accurate means, that you'll need to conserve space, then do so. But in general, be conservative with field sizes, and life shall be good.

Note that probably not all email clients support the RFC, so regardless of what it says, you may encounter different things in the wild.

Answer 2

The following email address is only 94 characters:

i.have.a.really.long.name.like.seetharam.krishnapillai@AReallyLongCompanyNameOfSomeKind.com.au

• Would an organisation actually give you an email that long?
• If they were stupid enough to, would you actually use an email address like that?
• Would anyone? Of course not. Too long to type and too hard to remember.

Even a 92-year-old technophobe would figure out how to sign up for a nice short gmail address, and just use that, rather than type this into your registration page.

Disk space probably isn't an issue, but there are at least two problems with allowing user input fields to be many times longer than they need to be:

• Displaying them could mess up your UI (at best they will be cut off, at worst they push your containers and margins around)
• Malicious users can do things with them you can't anticipate (like those cases where hackers used a free online API to store a bunch of data)

I like 50 chars:

123456789.123456789.123456789@1234567890123456.com

If one user in a million has to use their other email address to use my app, so be it.

(Statistics show that no-one actually enters more than about 40 chars for email address, see e.g.: ZZ Coder's answer https://stackoverflow.com/a/1297352/87861)

Answer 3

I use varchar(64) i do not think anyone could have longer email

Answer 4

If you're really being pendantic about it, make a username varchar(60), domain varchar(255). Then you can do ridiculous statistics on domain usage that is slightly faster than doing it as a single field. If you're feeling really gun-ho about optimization, that will also make your SMTP server able to send out emails with fewer connections / better batching.

Answer 5

I've in the past just done 255 because that's the so-ingrained standard of short but not too short input. That, and I'm a creature of habit.

However, since the max is 319, I'd do nvarchar(320) on the column. Gotta remember the @!

nvarchar won't use the space that you don't need, so if you only have a 20 character email address, it will only take up 20 bytes. This is in contrast to a nchar which will always take up its maximum (it right-pads the value with spaces).

I'd also use nvarchar in lieu of varchar since it's Unicode. Given the volatility of email addresses, this is definitely the way to go.

Answer 6

RFC 5321 (the current SMTP spec, obsoletes RFC2821) states:

4.5.3.1.1. Local-part

The maximum total length of a user name or other local-part is 64
octets.

4.5.3.1.2. Domain

The maximum total length of a domain name or number is 255 octets.

This pertains to just localpart@domain, for a total of 320 ASCII (7-bit) characters.

If you plan to normalize your data, perhaps by splitting the localpart and domain into separate fields, additional things to keep in mind:

• A technique known as VERP may result in full-length localparts for automatically generated mail (may not be relevant to your use case)
• domains are case insensitive; recommend lowercasing the domain portion
• localparts are case sensitive; user@domain.com and USER@domain.com are technically different addresses per the specs, although the policy at the domain.com may be to treat the two addresses as equivalent. It's best to restrict localpart case folding to domains that are known to do this.