What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For prices that need exact decimal values, use PostgreSQL numeric(p, s) and choose the precision and scale to fit your application’s limits and rounding rules. Avoid double precision for stored monetary amounts: it is an inexact binary floating-point type. Use money only if its locale-dependent fractional precision and formatting fit your application. For multi-currency data, store the currency identity separately from the amount.
Which PostgreSQL data type should you use for prices?
For most applications, numeric(p, s) is the appropriate choice when stored prices and calculations must preserve decimal exactness. PostgreSQL’s documentation specifically recommends numeric for monetary amounts and other quantities where exactness is required. Its arithmetic can be slower than integer or floating-point arithmetic, so choose it for the semantics your data needs, not as a universal performance choice. PostgreSQL 18: Numeric Types
The declaration’s precision and scale should reflect the application’s permitted range and business rules. For example, numeric(12,2) provides an explicit choice of up to 12 total digits, with 2 after the decimal point. It is an illustration, not a universal price schema: decide whether your data needs fractional minor units, tax calculations, exchange rates, or extra precision during intermediate calculations.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →How do numeric, double precision, and money compare?
| Type | Decimal behavior and scale | Locale and portability | Practical fit for prices |
|---|---|---|---|
numeric(p, s) |
Exact where possible; precision and scale are selectable. PostgreSQL documents up to 131,072 digits before and 16,383 digits after the decimal point for unconstrained numeric. The maximum explicitly specified precision is 1,000. |
The type itself does not format a value as locale-specific currency. | Default choice when exact decimal semantics matter. Arithmetic can be slower than integer or floating-point operations. |
double precision |
Inexact binary floating point, not a fixed number of decimal places. Uses 8 bytes and has at least 15 decimal digits of precision on currently supported platforms. | The type itself does not format a value as locale-specific currency. | Avoid for stored monetary values when exact decimal behavior matters. |
money |
Fixed fractional precision determined by lc_monetary. Uses 8 bytes; with two fractional digits, the documented range is -92233720368547758.08 to +92233720368547758.07. |
Output is locale-sensitive. A different lc_monetary setting can affect whether data loads correctly into another database. |
Consider only if its fixed scale, locale behavior, and arithmetic fit the application. Its documented range is a type limit, not a recommended business limit. |
The type characteristics and limits above are from the PostgreSQL 18 documentation, accessed in 2026; they are not performance benchmarks or recommended application limits. Numeric Types · Monetary Types
#1 Best Overall
Why shouldn’t you use double precision for money?
double precision represents values in binary floating point. Many decimal fractions cannot be represented exactly in that format, so a stored or calculated value may be an approximation. PostgreSQL describes real and double precision as inexact numeric types. That can make exact equality checks or accumulated monetary calculations surprising.
Use floating point only when approximate results are acceptable and that trade-off is deliberate. For prices, where a decimal amount is expected to remain exact, numeric is the safer fit. PostgreSQL 18: Numeric Types
Rank #2
Should you use numeric or money for currency in Postgres?
money is a built-in type for currency amounts, but its fractional precision depends on the database’s lc_monetary setting, and its output is locale-sensitive. As a result, formatted output is not a durable way to identify a currency, and different locale settings can complicate moving or restoring data. PostgreSQL notes that loading money data into a database with a different lc_monetary setting might not work.
numeric(p, s) gives the application explicit control over decimal scale and avoids making the amount’s display depend on a currency locale. For a system that supports several currencies, store a currency code or other currency identity separately from the numeric amount. A number such as 10.00 does not establish whether the value is USD, EUR, or another currency.
What does PostgreSQL money depend on when you divide it?
money has arithmetic behavior worth checking before adopting it. Integer division truncates toward zero, while division by another money value yields double precision. For rounded division, PostgreSQL recommends casting to numeric before dividing and casting back afterward rather than risking precision loss with a floating-point divisor. PostgreSQL 18: Monetary Types
Quick Recap
How should you choose precision and rounding for prices?
- Set precision to cover the maximum valid amount your application permits; PostgreSQL’s type limits are not a substitute for a business limit.
- Set scale to match the currency and application rules, including whether fractional minor units are valid.
- If tax, discounts, or exchange-rate calculations need more precision than the final payable amount, retain that precision during intermediate calculations and apply the defined rounding rule at the appropriate boundary.
- Choose and document the application’s rounding policy. PostgreSQL’s type documentation describes numeric and money behavior, but does not prescribe a universal accounting or tax rounding policy.
- Persist currency identity separately whenever records can represent more than one currency.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
