Foreign Key Constraint
A database-enforced rule that a referencing value must exist in the referenced table — referential integrity that no application bug can violate.
The value is that it holds regardless of which application, script, migration or console session wrote the data. Application-level checks protect the paths you remembered; a constraint protects all of them.
The costs are real and worth knowing. Every insert into the child table incurs a lookup on the parent. Deletes on the parent must check or cascade to children, which can be an expensive and lock-heavy operation on a large table. And in a sharded deployment the constraint cannot span shards at all, which is one of the specific capabilities sharding takes away.
The recurring architectural argument is whether to keep them in a service-oriented estate. Within one service's own schema: yes, almost always — they are free correctness. Across service boundaries: impossible, and the integrity obligation moves to the application or to an eventual reconciliation job.
Watch ON DELETE CASCADE specifically. It is convenient and it means a single delete can silently
remove a large subtree, which is a data-loss mechanism that looks like a feature.