Why You Should Rethink Using Foreign Keys in Modern Applications

Introduction

Although the topic is often debated, many developers avoid using foreign keys in practice. Even Alibaba's Java coding standards explicitly state:

"[Mandatory] Do not use foreign keys and cascade; all foreign‑key concepts must be resolved at the application layer."

When asked why, the common answer is that every DELETE or UPDATE operation must consider foreign‑key constraints, making development painful and testing data difficult to manage.

This article explains the full picture.

Main Content

First, a foreign‑key constraint is a rule that guarantees the relationship between tables remains complete, so it does have advantages:

Ensures data integrity and consistency.

Facilitates cascade operations.

Delegates integrity checks to the database, reducing application code.

However, these benefits come with significant drawbacks, which is why we generally do not recommend using foreign keys:

Performance Issues

Consider a table user_tb with two foreign‑key columns pointing to other tables. Each INSERT must query those tables to verify the referenced rows exist. If the application handles this logic, unnecessary queries can be avoided, but the database forces the checks.

Concurrency Issues

Modifying data that involves foreign keys requires additional locks on the referenced tables. In high‑traffic, transactional scenarios this increases the risk of deadlocks.

Scalability Issues

Platform migration becomes easier (e.g., moving from Mysql to Oracle) because you rely on application‑level logic rather than database‑specific features like triggers or foreign keys.

Sharding or horizontal partitioning is hindered because foreign keys cannot function across separate databases; moving relationship management to the application simplifies future scaling.

Technical Issues

Shifting integrity logic to the database increases its performance overhead and raises the skill requirements for DBAs. Many small‑to‑mid‑size companies lack dedicated DBAs and therefore prefer to avoid foreign keys to reduce database load. When the logic resides in the application, you can scale horizontally by adding more application servers, whereas a database‑centric approach often creates a bottleneck that is harder to scale.