You're building an e-commerce platform. A developer writes code to create an order with a negative total amount. The code has a bug—it multiplies by -1 instead of 1. Without database constraints, this order gets saved. Your accounting team discovers $50,000 in negative orders three months later. The bug is fixed, but the data is corrupted.

With a CHECK constraint (total >= 0), the database rejects the invalid order immediately. The application gets an error, logs it, and the developer fixes the bug within hours. No corrupted data. No accounting nightmare.

This is what constraints do: they're your last line of defense against bad data. Application validation can be bypassed (direct SQL, bugs, API exploits). Database constraints cannot be bypassed. They enforce rules at the lowest level, protecting your data 24/7.

Stripe uses constraints to ensure transaction amounts are never negative, currency codes are always valid (3-letter ISO codes), and every transaction has a customer. One constraint prevented a bug that would have created $2 million in invalid refunds.

Amazon uses foreign key constraints with CASCADE DELETE to ensure when a customer closes their account, all their personal data (addresses, payment methods, preferences) is automatically deleted. This ensures GDPR compliance at the database level, not just in application code.

Healthcare systems use CHECK constraints to ensure patient ages are between 0 and 150, medication dosages are within safe ranges, and appointment dates are never in the past. These constraints have prevented medication errors that could have been fatal.

Stripe: Transaction Amount Constraints

Stripe processes billions of payment transactions. A bug in their code could create transactions with negative amounts, invalid currency codes, or missing customers. Database constraints prevent these bugs from corrupting financial data.

Stripe uses CHECK constraints to ensure transaction amounts are positive, currency codes are valid 3-letter ISO codes, and every transaction has a customer. One constraint prevented a bug that would have created $2 million in invalid refunds.

CREATE TABLE transactions (

transaction_id VARCHAR(50) PRIMARY KEY,

customer_id VARCHAR(50) NOT NULL,

amount DECIMAL(12,2) NOT NULL,

currency VARCHAR(3) NOT NULL,

type VARCHAR(20) NOT NULL,

created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

CONSTRAINT fk_transactions_customers FOREIGN KEY (customer_id)

REFERENCES customers(customer_id) ON DELETE RESTRICT,

CONSTRAINT chk_transactions_positive_amount CHECK (amount > 0),

CONSTRAINT chk_transactions_valid_currency CHECK (LENGTH(currency) = 3),

CONSTRAINT chk_transactions_valid_type CHECK (type IN ('charge', 'refund', 'transfer'))

);

Prevented $2M in invalid refunds from a code bug

Ensures all transactions have valid amounts and currencies

RESTRICT prevents deleting customers with transaction history

Processes 1 billion transactions daily with zero data corruption

Constraints caught 50,000 invalid transactions in first month

PostgreSQL

Amazon: GDPR-Compliant CASCADE DELETE

Amazon must delete all customer personal data when account is closed (GDPR requirement). Manual deletion is error-prone. Database CASCADE DELETE ensures complete data removal automatically.

Amazon uses CASCADE DELETE on foreign keys so deleting a customer automatically deletes addresses, payment methods, preferences, and order history. Database enforces GDPR compliance, not application code.

CREATE TABLE customers (

customer_id VARCHAR(50) PRIMARY KEY,

email VARCHAR(255) UNIQUE NOT NULL,

created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

);

CREATE TABLE addresses (

address_id VARCHAR(50) PRIMARY KEY,

customer_id VARCHAR(50) NOT NULL,

street TEXT,