Why can't floating point store 0.1 exactly?

Binary floating point represents numbers as sums of powers of two, and one tenth is a repeating fraction in binary, like one third in decimal. The stored value is the nearest representable double, so 0.1 + 0.1 + 0.1 yields 0.30000000000000004 and the error compounds with every operation.

Why does the displayed amount hide float drift?

Display formatting rounds to two decimals, so a drifted balance still prints as $0.30. The drift surfaces where money actually gets checked: equality comparisons, reconciliation against another system, and invariants like debits equal credits, which fail on differences too small to print.

Should money be integer cents or a DECIMAL column?

Both are exact. Integer minor units (cents) are the simplest and portable across every language and database; DECIMAL or NUMERIC is the right tool when fractional precision is inherent, such as FX rates or unit prices with sub-cent precision. The one wrong answer is binary floating point.

What about currencies without two decimals?

Minor units are per currency: Japanese yen has zero decimal places, Bahraini dinar has three. Storing integer minor units plus the currency code handles all of them; the display layer applies the currency's exponent when formatting.

Failure Modes Float Drift → Integer Cents

Three dimes.
Not thirty cents.

Binary floats cannot store a dime: 0.1 has no exact representation. Charge three of them: the float ledger drifts and its checks start failing, while integer cents stay exact forever.

charged $0.00

Naive, sums doubles

balance: $0

ledger amount DOUBLE

stored 0

displayed $0.00

expected 0

stored == expected …

Integer cents, sums exactly

balance: $0

ledger amount_cents BIGINT

stored 0¢

displayed $0.00

expected 0¢

stored == expected …

Charge a few dimes: both ledgers just add ten cents each time. Watch the third one. The float ledger drifted: the display rounds it away, but the equality check fails, and checks are what reconciliation runs on.

How integer money actually works read more

One tenth is a repeating fraction in binary, so a double stores the nearest representable number instead. The display rounds the drift away, which is exactly what makes it dangerous: the checks money runs on do not round. Equality, reconciliation against the processor, debits-equal-credits: all of them fail on a difference too small to print.

The fix is the schema, not the arithmetic:

amount DOUBLE               -- 0.1 + 0.1 + 0.1 = 0.30000000000000004

amount_cents BIGINT NOT NULL   -- 10 + 10 + 10 = 30, exactly, forever

Integer minor units make every add and compare exact, in every language and database. When fractional precision is inherent, like FX rates, use DECIMAL, which is exact too. The one wrong answer is binary floating point.

The cost: formatting moves to the display layer, and minor units are per currency (yen has zero decimals, Bahraini dinar has three), so the amount travels with its currency code.