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 usually still prints as $0.30. The drift surfaces where money actually gets checked: zero checks that settle an invoice, equality in reconciliation, and invariants like debits equal credits fail on differences too small to print, and naive formatting leaks the sign back out as $-0.00.

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

Paid in full.
Still owes $-0.00.

A 30¢ invoice, paid in three 10¢ installments. Computers store 0.1 the same way you'd write 1/3 in decimal: it never divides evenly. Add three of them and you get 0.30000000000000004, not 0.3.

paid $0.00

Naive, sums doubles

invoice: UNPAID

invoice, 30¢ DOUBLE

stored value

total

remaining $0.30

Integer cents, sums exactly

invoice: UNPAID

invoice, 30¢ BIGINT

stored value

total

remaining $0.30

Pay off the 30¢ invoice in 10¢ installments and watch each system settle it. The customer paid in full, but the naive invoice's remainder never hits exactly zero.

How integer money actually works read more

0.1 has no exact binary form, so the computer stores the closest value it can. Every mainstream language works the same way, so they all land on 0.30000000000000004 for three dimes.

The display rounds that away, which is what makes it dangerous: money code checks for an exact zero, not a rounded one. Rounding doesn't fix the drift, it just hides it. Enough payments, and it crosses a real cent.

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 cents make every add and compare exact, in any language, in any database. Need real fractions, like an FX rate? DECIMAL is exact too. Floating point is the one that isn't.

The cost: formatting moves to the display layer, and the decimal count depends on the currency (yen has none, Bahraini dinar has three), so the amount has to travel with its currency code.