Nobody demos a storage layer. It is also the component that determines whether you can serve your tenth thousand user or your ten millionth, and whether recovering from a bad deploy is an incident or a footnote.

Write once, read many times

The shape of a content system follows from access patterns. Content that is written rarely and read constantly -- articles, docs, marketing pages -- wants a denormalised record with the rendered output stored alongside the source, not joined at read time.

That single decision removes the most expensive query in most naive implementations, and it makes the read path a single lookup that any cache can serve.

Soft deletes are not a compromise

Marking a record with a timestamp costs one nullable column and buys you an undo. Cascading a hard delete to related rows costs you the ability to explain what happened afterwards.

Filter deleted rows in every query, and put the condition in the index. A soft delete you forget to filter is worse than a hard delete, because the rows are still there being served.

Recovery is a product feature

Ask what restoring a single piece of content looks like, and how long it takes. If the answer involves a restore from backup, the recovery window is measured in hours and someone will be explaining that to a customer.

A soft delete plus an audit column gives you a per-item restore in seconds. It is the cheapest reliability feature available in a content product, and almost nobody builds it first.