How to Mock Data with Complex Composite Foreign Keys

Single-column foreign keys are easy. But in enterprise multi-tenant SaaS applications, you frequently encounter Composite Foreign Keys—where a relationship is defined by two or more columns acting together.

Generating synthetic test data for composite keys breaks almost every open-source mocking tool on the market.

The Code Problem: The Multi-Tenant Trap

-- 1. The Parent Table (Composite Primary Key)

CREATE TABLE tenant_users (

tenant_id UUID,

user_id UUID,

role VARCHAR(50),

PRIMARY KEY (tenant_id, user_id)

);

-- 2. The Child Table (Composite Foreign Key)

CREATE TABLE user_audit_logs (

log_id UUID PRIMARY KEY,

tenant_id UUID,

user_id UUID,

action VARCHAR(255),

-- The constraint spans TWO columns

FOREIGN KEY (tenant_id, user_id) REFERENCES tenant_users(tenant_id, user_id)

);

Why Faker.js and Custom Scripts Fail

A generic script might successfully query the parent table to get a list of valid tenant_ids and user_ids. But if it randomly assigns a tenant_id and randomly assigns a user_id to the audit log, it will create a tuple that doesn't actually exist in the parent table (e.g., assigning User B to Tenant A's log). The database rejects the row instantly.

The Aphelion Solution

Aphelion builds a topological dependency graph. When it detects a composite foreign key, it treats the multi-column tuple as a single unified entity. When it populates the child table, it pulls the exact paired (tenant_id, user_id) tuple directly from the parent, ensuring perfect multi-column referential integrity.

Recipe: Seeding Composite Keys

# 1. Map the composite dependencies

aphelion introspect postgres://admin:password@localhost:5432/saas_db

# 2. Generate valid multi-tenant logs

aphelion generate --table user_audit_logs --rows 100000 --seed 2026