Why should you store third-party API keys in Vault instead of a plain table column?

A plain column holding an API key is stored as ordinary plaintext data: anyone with SELECT access to that table — a teammate with dashboard access, a misconfigured RLS policy, a database backup that leaks — can read the key directly with no extra step. It's also indistinguishable from any other piece of application data, so it's easy to accidentally include in a query result, a log line, or an exported CSV without realizing it's sensitive.

Vault treats the secret as a distinct, encrypted object from the moment it's written: it's encrypted at rest, decryption is gated behind its own permission (the vault.decrypted_secrets view), and it's clearly marked as a secret in the schema rather than looking like an ordinary text column. This narrows the blast radius of common mistakes — a broad RLS policy or an over-permissioned service role still won't expose the plaintext unless it specifically has decrypt access — and makes it much harder to accidentally leak the key through a routine query, log export, or backup.