What is the difference between a primary key and a unique constraint?

Someone asked me this question on an interview...

Primary keys can't be null. Unique keys can.

A primary key is a unique field on a table but it is special in the sense that the table considers that row as its key. This means that other tables can use this field to create foreign key relationships to themselves.

A unique constraint simply means that a particular field must be unique.

1. Primary key can not be null but unique can have only one null value.
2. Primary key create the cluster index automatically but unique key not.
3. A table can have only one primary key but unique key more than one.

TL;DR Much can be implied by PRIMARY KEY (uniqueness, reference-able, non-null-ness, clustering, etc) but nothing that can't be stated explicitly using UNIQUE.

I suggest that if you are the kind of coder who likes the convenience of SELECT * FROM... without having to list out all those pesky columns then PRIMARY KEY is just the thing for you.

a relvar can have several keys, but we choose just one for underlining and call that one the primary key. The choice is arbitrary, so the concept of primary is not really very important from a logical point of view. The general concept of key, however, is very important! The term candidate key means exactly the same as key (i.e., the addition of candidate has no real significance—it was proposed by Ted Codd because he regarded each key as a candidate for being nominated as the primary key)... SQL allows a subset of a table's columns to be declared as a key for that table. It also allows one of them to be nominated as the primary key. Specifying a key to be primary makes for a certain amount of convenience in connection with other constraints that might be needed

What Is a Key? by Hugh Darwen

it's usual... to single out one key as the primary key (and any other keys for the relvar in question are then said to be alternate keys). But whether some key is to be chosen as primary, and if so which one, are essentially psychological issues, beyond the purview of the relational model as such. As a matter of good practice, most base relvars probably should have a primary key—but, to repeat, this rule, if it is a rule, really isn't a relational issue as such... Strong recommendation [to SQL users]: For base tables, at any rate, use PRIMARY KEY and/or UNIQUE specifications to ensure that every such table does have at least one key.

SQL and Relational Theory: How to Write Accurate SQL Code By C. J. Date

In standard SQL PRIMARY KEY

• implies uniqueness but you can specify that explicitly (using UNIQUE).
• implies NOT NULL but you can specify that explicitly when creating columns (but you should be avoiding nulls anyhow!)
• allows you to omit its columns in a FOREIGN KEY but you can specify them explicitly.
• can be declared for only one key per table but it is not clear why (Codd, who originally proposed the concept, did not impose such a restriction).

In some products PRIMARY KEY implies the table's clustered index but you can specify that explicitly (you may not want the primary key to be the clustered index!)

For some people PRIMARY KEY has purely psychological significance:

• they think it signifies that the key will be referenced in a foreign key (this was proposed by Codd but not actually adopted by standard SQL nor SQL vendors).
• they think it signifies the sole key of the table (but the failure to enforce other candidate keys leads to loss of data integrity).
• they think it implies a 'surrogate' or 'artificial ' key with no significance to the business (but actually imposes unwanted significance on the enterprise by being exposed to users).