U vkládání, aktualizací a mazání dochází k malému snížení výkonu, protože je třeba zkontrolovat FK. U jednotlivých záznamů by to bylo normálně tak nepatrné, že by to bylo nepostřehnutelné, pokud nezačnete mít ke stolu přidružený směšný počet FK (Očividně trvá kontrola 100 jiných stolů déle než 2). To je dobrá věc, ne špatná věc, protože databáze bez integrity jsou nedůvěryhodné, a proto k ničemu. Integritu byste neměli vyměňovat za rychlost. Tento zásah do výkonu je obvykle kompenzován lepší schopností optimalizovat plány provádění.
Máme středně velkou databázi s přibližně 9 miliony záznamů a FK všude, kde by měly být, a málokdy si všimneme výpadku výkonu (kromě jedné špatně navržené tabulky, která má hodně přes 100 cizích klíčů, je trochu pomalé mazat záznamy z této nutno zkontrolovat). Téměř každý dba, o kterém vím, že se zabývá velkými databázemi o velikosti terabajtů a skutečnou potřebou vysokého výkonu na velkých souborech dat, trvá na omezeních cizích klíčů, protože integrita je klíčem k jakékoli databázi. Pokud si lidé s databázemi o velikosti terabajtů mohou dovolit velmi malý zásah do výkonu, můžete si to dovolit i vy.
FK nejsou automaticky indexovány a pokud nejsou indexovány, může to způsobit problémy s výkonem.
Upřímně řečeno, vzal bych kopii vaší databáze, přidal správně indexované FK a ukázal časový rozdíl pro vkládání, mazání, aktualizaci a výběr z těchto tabulek ve srovnání se stejnou z vaší databáze bez FK. Ukažte, že nezpůsobíte výkonnostní hit. Poté zobrazte výsledky dotazů, které ukazují osiřelé záznamy, které již nemají význam, protože PK, ke které se vztahují, již neexistuje. Obzvláště efektivní je to ukázat u tabulek, které obsahují finanční informace ("Máme 2700 objednávek, které nemůžeme přiřadit k zákazníkovi", vedení si sedne a všimne si toho).