It always depend on the use case you are trying to model. My statement was primarily a counterpoint to OP "you might at well timestamp it". I guess it is a val

It always depend on the use case you are trying to model. My statement was primarily a counterpoint to OP "you might at well timestamp it". I guess it is a valid take on the specific use case of publication date he mention. The problem is generalizing from that. For user inputed data you might NOT want to coerce a default state when the user genuinely can't answer otherwise you might collect garbage because i can guarantee that the user will input random answer to unblock itself. Of course you can define enum, but the NULL value already cover 80% of use case when used properly (as far as database are concerned). NOT null might be a useful DB constraint (especially for ids participating columns). But you just have to read PostgreSQL release notes to notice that null handling is actually a hot topic which always call for more fine tuned settings to accommodate different workflow. People use theses features a lot. See : https://news.ycombinator.com/item?id=32053293 https://news.ycombinator.com/item?id=32053293 As far as JOIN are concerned bad NULL handling is almost always coming from a bad understanding of OUTER JOIN mechanics. Anyhow it's an endless debate and I guess we won't be able to settle the NULL Schism tonight! See : https://news.ycombinator.com/item?id=18588239 https://news.ycombinator.com/item?id=18588239 So maybe let us end with this beautiful quote from last link top comment by @porpoisely NULL exists to solve particular problems in computer science. It can also cause a lot of problems. You can argue it's the best solution and worst mistake depending on the situation.