Table (n.) – a collection of information (data?) describing a population of entities which possess some common characteristics, called attributes. Tables are the building block of relational databases.  Tables must generally be “normalized,” at least to 1NF.  That may be an appropriate way to think of databases when implemented in a modern day DBMS.  However, it is not the way the world thinks logically. People have no problem with commonly occurring phenomena such as:
* A multi-valued attribute, e.g., an Employee possesses multiple Skills.
* Many-to-many (M:N) relationships, e.g., as between Employees and Projects
* A relationship with attributes
--Gordon Everest, Recognizing and Treating Tableitis

JN: It's an unfortunate bit of propaganda. Some truth mixed in with distractions and irrelevant comparison. I've met the DataStax team. They're smart people with a solid understanding of their space. I'm disappointed to see them mix good and bad information into something that looks like objective truth.

According to Wikipedia, Amazon's Redshift is a modified version of Postgres.
Maybe its speed redshifted data integrity into a bloody mess.

It has no primary keys, foreign keys or unique constraints. It just has optimizer hints in the DDL that *maybe* the data behaves that way. If they want to put hints in the DDL, OK, but don't call those hint PRIMARY KEY, FOREIGN KEY or UNIQUE.
--Unsupported PostgreSQL Features - Amazon Redshift

I don't think any version of Postgres lets you say Create Table Foo (Bar Int PRIMARY KEY) and then let you do

INSERT INTO Foo (BAR) Values (42)
INSERT INTO Foo (BAR) Values (42)
INSERT INTO Foo (BAR) Values (42)

That might be fine for a one time only static data warehouse, but an ongoing data update system is going to break the integrity rules, it is just a matter of time. That would make for some surprises when someone decides to migrate their data and lots of application code from a relational DBMS to Redshift.
--Jeff Winchell