Using VARCHAR for dates: birth_date VARCHAR(20)

Use DATE type: birth_date DATE

DATE type validates automatically and enables date calculations (age, date ranges).

Always use proper date types for date data

High

Can store invalid dates like "2024-02-30" or "abc"

Using FLOAT for money: price FLOAT

Use DECIMAL: price DECIMAL(10,2)

DECIMAL provides exact precision required for financial data and legal compliance.

DECIMAL for money, FLOAT for scientific data only

Critical

Rounding errors: 10.10 becomes 10.099999904632568

Forgetting NOT NULL: email VARCHAR(100)

Add NOT NULL: email VARCHAR(100) NOT NULL

Use NOT NULL for all fields that are truly required by business logic.

NOT NULL prevents missing required data

High

Allows NULL emails, breaks application logic

Implicit conversion in JOIN/WHERE: varchar_col = 123

varchar_col = '123' or CAST(123 AS VARCHAR)

Implicit conversions prevent index usage, causing table scans on large datasets.

Always match column data type in predicates for index usage

High

Full scan, no index. varchar_col = 123 forces type conversion on every row

FLOAT for currency: 0.1 + 0.2 = 0.3000000004

DECIMAL(12,4) or INTEGER cents

FLOAT uses binary representation causing precision loss. Use DECIMAL for exact arithmetic or store cents as INTEGER.

Store money as DECIMAL or INTEGER cents (amount_cents INT)

Critical

Binary floating-point cannot represent 0.1 exactly, accumulates errors

TIMESTAMP without TZ in multi-region apps

TIMESTAMPTZ + app TZ handling

TIMESTAMP stores local time without timezone info. TIMESTAMPTZ stores UTC internally, converts on display.

Always use TIMESTAMPTZ for global apps, store UTC

High

Wrong time displayed in different regions, DST bugs