rust_decimal vs bigdecimal: Money Types in Rust

The pages ranking for "rust_decimal vs bigdecimal" mostly stop at "fixed-size and fast versus arbitrary precision", which is true and not enough to choose with. So I built a scratch crate against rust_decimal 1.43.0 and bigdecimal 0.4.11 on Rust 1.98 and ran the cases payment code hits: token amounts, rounding, JSON, Postgres and overflow. Unless I say otherwise, every output below is pasted from that run.

How Should You Represent Money in Rust?

There are five realistic options, and one of them is wrong.

Integer minor units are what Stripe and Adyen put on the wire, and what I used for the Postgres schema in the TigerBeetle vs Postgres ledger guide. An i64 holds 92,233,720,368,547,758.07 when the unit is pence. No fiat ledger gets close. The same i64 holds 9.223372036854775807 ETH when the unit is wei. That gap between fiat and 18-decimal tokens shapes most of what follows.

rust_decimal vs bigdecimal vs fastnum in 2026: Which Crate?

fastnum is the one most comparisons skip. It is fixed-size like rust_decimal, but a D256 holds 77 significant digits, which covers any realistic 18-decimal token balance. It is still pre-1.0 and needs Rust 1.94. Its default rounding is half-up, so swapping it in for rust_decimal changes every midpoint result without a compile error.

Two others turn up in searches. rusty-money 0.5.1 wraps rust_decimal with 150-plus ISO 4217 currencies and 14 crypto assets, and its fast feature adds an i64 FastMoney that truncates; it went five years between releases (January 2021 to January 2026). The fixed crate, with 16.3M downloads, is binary fixed-point, so 0.1 has no exact representation in it.

bigdecimal's defaults are also fixed at compile time. Its build.rs reads RUST_BIGDECIMAL_DEFAULT_PRECISION (default 100) and RUST_BIGDECIMAL_DEFAULT_ROUNDING_MODE (default HalfEven), so an environment variable set in CI changes the result of a / b for every crate in the build. That is a strange place to keep a business rule. If you use bigdecimal for money, pass precision and rounding mode explicitly at each call.

What Is the Maximum Value of rust_decimal?

Decimal::MAX / 1e18 = 79228162514.264337593543950335

That is roughly 79.2 billion whole tokens. For USDC, with 6 decimals, the limit never matters. For 18-decimal ERC-20s it is a real ceiling: an individual DAI balance fits easily, but a pool reserve or a total supply in the hundreds of billions does not, and intermediate products such as price * amount hit it long before the inputs do.

What happens above the ceiling depends on which constructor you call:

If amounts arrive as strings from a chain indexer, a PSP or a bank file, parse them with from_str_exact and treat the error as a rejected message. For on-chain values I would not use either decimal crate as the source of truth. Keep the raw integer as U256 from alloy-primitives, or u128 if you have checked the token's supply, and convert to Decimal only for display or pricing.

Does rust_decimal Panic on Overflow?

Yes. The operators panic, and the checked methods return None:

Decimal::MAX + dec!(1)                → panic: "Addition overflowed"
dec!(1) / dec!(0)                     → panic: "Division by zero"
Decimal::MAX.checked_add(dec!(1))     → None
dec!(1).checked_div(dec!(0))          → None
Decimal::MAX.saturating_add(dec!(1))  → 79228162514264337593543950335

A panic is at least loud. Multiplication that needs more than 28 significant digits rounds instead of failing:

1.2345678901234567890123456789 * 1.2345678901234567890123456789
                                       = 1.5241578753238836750495351563
0.0000000000000000000000000001 * 0.5   = 0.0000000000000000000000000000
(dec!(1) / dec!(3)) * dec!(3)          = 0.9999999999999999999999999999

For the overflow case, let Clippy enforce checked arithmetic instead of relying on review. Setting arithmetic_side_effects = "warn" under [lints.clippy] in Cargo.toml flags + and * on Decimal and on BigDecimal, not only on primitive integers; it fired on all four functions in my test crate. Types you have audited can be exempted with arithmetic-side-effects-allowed in clippy.toml.

Which Rounding Mode Does rust_decimal Use?

Both round() and round_dp() use banker's rounding, where a midpoint goes to the nearest even digit:

The last row is the bigdecimal trap. with_scale(2) reads like "set to two decimal places", and it truncates. Use round(2) or with_scale_round(2, RoundingMode::HalfUp) and name the mode you mean.

Banker's rounding is a reasonable default for statistics. For customer-facing money it is a choice you should make on purpose. Postgres round(numeric) rounds half away from zero, so round(0.125, 2) in SQL gives 0.13 while round_dp(2) in Rust gives 0.12. If both layers round, they will disagree on exactly the values a customer notices. I covered the same split between Postgres and Python in the ISO 4217 minor units guide.

UK VAT Rounding Rules in Rust (HMRC Notice 700)

For UK VAT invoices you don't get to pick the rounding mode. HMRC VAT Notice 700 §17.5 lets invoice traders round the invoice's total VAT down to a whole penny. If you work VAT out per line (§17.5.1), each line rounds either down to the nearest 0.1p or to the nearest 1p or 0.5p, and "whatever you decide, you must be consistent". Retailers who calculate at line or invoice level must not round down at all (§17.6).

Mapped to rust_decimal, with a line VAT of £0.8676:

Two things follow. The 0.1p option keeps line VAT in tenths of a penny, so an integer-pence type cannot hold it until the invoice total is rounded. And no built-in strategy implements the per-unit rule in §17.5.2: round to the nearest 0.5p, but never round standard- or reduced-rate VAT to nil. HMRC's own example turns £0.0024 into £0.005. That is a branch you write and test yourself. Credit notes need a decision as well: for −£0.8676, ToZero gives −0.867 and ToNegativeInfinity gives −0.868, and "round down" doesn't say which one it means.

How Do You Serialise rust_decimal to JSON Without Losing Precision?

Both crates serialise to a JSON string by default, {"v":"1.10"}, with trailing zeros kept because the scale is part of the value. Leave that default alone. The damage happens on the way in, and through feature flags:

A JSON number goes through f64 unless serde_json's arbitrary_precision feature is on. rust_decimal then takes the shortest round-trip form of the float, which hides the damage for short values. bigdecimal keeps the float's exact binary expansion, which makes it obvious. Neither survives a 22-digit number. Turning on arbitrary_precision fixed every row for both crates in my test. It is a Cargo feature, though, so it unifies across the dependency graph and changes serde_json::Number for every crate in the binary.

rust_decimal's serde-with-float option writes 1.10 as 1.1 and 12345678901234567890.12 as 1.2345678901234567e+19. Do not use it for amounts.

bigdecimal has one more surprise. Its Display switches to exponent notation after five leading zeros: 0.000001 prints as 0.000001, but 0.0000001 prints as 1E-7, and serde sends the string "1E-7". A bank or PSP API expecting a plain decimal will reject that. to_plain_string() returns 0.0000001. The threshold is another build-time variable, RUST_BIGDECIMAL_FMT_EXPONENTIAL_LOWER_THRESHOLD.

Equality has a related catch. In rust_decimal dec!(1.10) == dec!(1.1) is true and both hash the same, but to_string() gives "1.10" and "1.1". If you build an idempotency fingerprint or an HMAC over the string form, two equal amounts produce two different keys. Normalise or format to the currency's exponent first; the idempotency keys guide covers why fingerprints need a canonical body.

Postgres NUMERIC in Rust: sqlx, Diesel or SeaORM?

The mapping is settled. What happens at the edges isn't.

Postgres NUMERIC allows 131,072 digits before the decimal point and 16,383 after. rust_decimal holds 28 in total, so writes never fail and reads can:

• NaN is rejected by every Decimal and BigDecimal decoder.
• An integer part above 7.9 × 10²⁸ fails. sqlx returns "value not representable as rust_decimal::Decimal". This is the one that catches crypto schemas: NUMERIC(78,0) is the usual column for a uint256, and any balance above 79.2 billion tokens in wei will not decode into a Decimal.
• More than 28 decimal places is where the drivers disagree. rust_decimal's own tokio-postgres code rescales and rounds. sqlx 0.9 multiplies each base-10,000 digit group by 10,000 to the power of its weight, and 10,000⁻⁸ is not representable, so a non-zero digit past the 28th decimal place fails the whole row. I ran sqlx's decode loop against rust_decimal 1.43 to check. Same type, same column: one driver rounds and the other errors.
• An oversized BigDecimal on write is encoded by sqlx as a deliberately invalid value, and the query fails with 22P03 invalid_binary_representation.

Is rust_decimal Fast Enough? Benchmark vs i64

I ran a quick release-mode loop on an Apple M5 Pro, with std::hint::black_box around inputs and outputs. Treat the numbers as orders of magnitude, not a benchmark suite:

rust_decimal costs about 10x an integer, and bigdecimal about 13x rust_decimal once a multiply allocates. Six nanoseconds per multiply-and-round will never be the slow part of a payment request; one Postgres round trip costs thousands of times more. It only shows up in batch work, such as nightly interest accrual over millions of accounts.

i64 Minor Units vs Decimal: Which Should a Payment Ledger Use?

My position, and it is an opinion: store balances and postings as integers in minor units, compute with Decimal, and keep BigDecimal at the edges.

The ledger stores i64 (or u128 for tokens) plus a per-asset exponent. TigerBeetle forces that model on you, since its amounts are u128 integers, and Stripe exposes it in its API. An integer cannot carry a scale mismatch: 1.10 and 1.1 cannot both exist in the table. Rates, fee percentages, VAT, FX conversion and pro-rata splits are computed in Decimal, because that is where fractional minor units appear. The conversion from Decimal to integer minor units happens in one function, with an explicit rounding strategy, and the remainder is posted somewhere visible rather than dropped. BigDecimal is for inputs that can legitimately exceed 28 digits, mainly crypto amounts arriving as strings, and those get validated and converted before they reach the ledger.

The alternative, Decimal all the way down with NUMERIC(19,4) columns, works. Plenty of teams run it. My objection is that it lets fractional pennies into balances that nobody can pay out, and the reconciliation report is where you find out.

What This Means for Rust Payment Teams

1. Wrap amounts in a type. struct Money { minor: i64, currency: Currency }, with no f64 constructor and the exponent taken from the currency. 2. Parse external decimal strings with from_str_exact and reject on error. Never parse() an amount from a third party. 3. Turn on clippy::arithmetic_side_effects in the crates that touch balances, and use checked_add, checked_mul and checked_div. 4. Keep serde's string format. If you must accept JSON numbers, enable arbitrary_precision and add a test with a 20-digit value. 5. Never use bigdecimal's with_scale to round. Use round or with_scale_round with a named mode, and use to_plain_string() for anything sent to another system. 6. Round in one layer. Either Rust or SQL, with the mode written down next to the function. 7. Check token decimals against the 79.2 billion ceiling before you put an 18-decimal asset in a Decimal. Keep raw on-chain values as U256 or u128. 8. Property-test the round trip with rust_decimal's proptest feature: string to Decimal to Postgres and back should be the identity.

Key Takeaways

• Decimal::from_str silently rounds digits beyond 28; from_str_exact returns Err(Underflow). At 18 decimals the ceiling is 79,228,162,514 whole tokens.
• Operators panic on overflow, but a multiplication needing more than 28 digits rounds, and checked_mul still returns Some.
• rust_decimal rounds half to even, Postgres round() half away from zero, and bigdecimal's with_scale truncates.
• Without serde_json's arbitrary_precision, a JSON number 0.1 becomes a 55-digit BigDecimal, and bigdecimal writes 0.0000001 as "1E-7".
• sqlx errors on NUMERIC values past 28 decimal places that rust_decimal's own driver rounds.