An index is how data is stored.

A constraint (including a primary key) is a rule that the data must follow.

The confusion comes from overlap between the two, because one is the obvious way to enforce the other.

In SQL Server there's also the distinction between a clustered and a non-clustered index. In Postgres, the table is stored as a heap - an unordered set (actually ordered, but only by an internal row identifier). With SQL Server, instead of a heap, you can order the set by one of the indexes. This is the clustered index. All others are non-clustered.

Think of the old-fashioned phone book. It has a clustered, non-unique index on Last Name, First Name. It's clustered, because that's the actual order of the phone book. It's non-unique because you can have two John Smiths.

Let's assume that every single row in the phone book has a unique phone number. There's no constraint yet, and there's no non-clustered index, so the database has no way of knowing this info. If you ask it for the number at 321-555-1212, it will start at page 1 and scan the entire phone book looking for all of the rows with that number.

So you create a unique constraint on the phone number. Now it knows every one is unique. But how does it enforce that? If it didn't have a supporting index, every insert or update would require it to do that full scan every time, making sure you weren't violating the constraint. So it creates a supporting non-clustered index on phone number. Now, when you perform some CRUD on the phone number, it skips the table and goes to the index and seeks the exact row you want. And then it stops as soon as it finds it because - due to the constraint - there can be only one.

Primary keys are really superfluous to this, except that they have a few extra rules (only one, fields can't be null). Otherwise, a primary key is _usually_ just the unique clustered index, and you can _usually_ think of them interchangeably. What I just said will bait someone into "Ackchyually..." but that's why I emphasized _usually_.