One nitpick is that "user" is a reserved word in PG, so "users" is better.
Other than that, I'd agree with most suggestions. But I'd use MySQL. :)
Source: DBA.
The advice is to set NOT NULL if you think the field can't be null. That's valid, and a matter of encoding the schema to correctly match the data. Same with check values. Keep bad data out of the database wherever you can.
> and constraints are not high-performance
Then turn off constraint checking after you've built your schema and identified them as a performance problem. Don't optimize away your data integrity before you've even determined it's a problem.
If you actually don't care about your schema, just use a text field and throw whatever in it, or use a document store without any strict checking. If you're using SQL, presumably you're using it for a reason, and that's likely so you can take advantage of what it has to offer.
And re constraints: eh, for most applications this feels like premature optimization. My usual approach is to include whatever constraints are easy to express, but also have the application not rely on the DB for enforcement. That way you get some extra safety checks that might catch bugs, but if they do become a bottleneck you can just drop them.
Not a DBA, just a software dev who's learned not to sacrifice safety for perf unless there's a clear, demonstrable need.
Would that be a good idea? Maybe.