CockroachDB changes decimal rounding to match PostgreSQL
The February beta replaces CockroachDB's decimal implementation and makes half-away-from-zero rounding the default. Existing calculations can change without a schema change.
A database upgrade can change a calculation even when the column type and SQL expression stay the same. CockroachDB's February 23 beta replaces its DECIMAL implementation and changes default rounding to half away from zero. The release notes explicitly warn that some calculation results may change, while identifying PostgreSQL compatibility as the reason for the new default behavior.
Half away from zero resolves an exact midpoint by choosing the value with greater magnitude. At integer precision, a positive midpoint such as 2.5 goes to 3, while a negative midpoint such as -2.5 goes to -3. The negative case is worth spelling out because rounding away from zero is different from always rounding toward a larger signed value.
I care about PostgreSQL compatibility as a way to make adoption less costly, but numeric behavior is a particularly consequential part of it. A query can connect, parse, and return a correctly typed result while still implementing a different rounding rule. This beta changes that semantic detail directly.
The implementation change reaches existing expressions
The implementation pull request, merged February 22, replaces inf.dec with apd.Decimal. Its notes call attention to the effect on ROUND behavior. The release announcement therefore describes an implementation replacement with visible SQL consequences, not simply a new optional function.
That distinction determines the affected application population. Code does not have to opt into a new type name to encounter the change. Existing decimal calculations can use the replacement implementation when they run against the new beta. A migration that changes no schema can still produce different numeric output.
The warning is intentionally broader than a claim that only one named query form changes. The release says some calculations may differ. It does not provide an exhaustive equivalence proof for every decimal operation, and the implementation discussion separately notes questions around logarithm behavior. The verified compatibility improvement is the documented default rounding rule.
It would also be misleading to describe decimal arithmetic as requiring no approximation simply because it avoids binary floating-point representation. Rounding policy still has to define a result when an operation or requested precision cannot preserve every digit. This beta makes a particular tie-breaking choice consistent with PostgreSQL.
Matching a familiar database requires matching results
Driver compatibility is often demonstrated with successful connections and ordinary queries. Numeric compatibility needs stronger examples because two systems can agree on accepted syntax and result types while disagreeing at a rounding boundary. Exact midpoints are where the newly documented rule becomes observable.
Negative values are particularly informative. Away-from-zero rounding treats the sign symmetrically in magnitude, so a negative tie moves farther below zero. A rule described loosely as rounding up can conceal that difference. The beta's terminology gives applications a precise behavior to compare with their required calculation policy.
Application code may also perform rounding outside the database. If that code uses another rule, aligning CockroachDB with PostgreSQL does not automatically align it with the application. The relevant contract is the arithmetic the application needs, wherever each part of the calculation runs. Database compatibility removes one possible difference while leaving that contract to be expressed clearly.
I regard the explicit result-change warning as useful release information. A storage or arithmetic library replacement can sound internal, yet a changed value is an application-visible outcome. Naming the default policy lets readers reason about the affected cases instead of treating the update as invisible maintenance.
Other compatibility details remain deliberately narrow
The beta fixes parsing of interval constants with precision modifiers and accepts certain boolean-like string literals where a boolean is required. The latter change does not apply generally to placeholders or arbitrary string expressions. That qualification shows the same need to distinguish a specific accepted form from broad type-conversion compatibility.
Catalogue work continues as well. pg_index.indkey becomes an int2vector to improve compatibility with Sequelize, and SHOW result headers become lowercase to match PostgreSQL. Array support improves but remains restricted to catalogue tables. These changes address concrete assumptions made by clients inspecting metadata.
A tool can depend on a column's database type as well as its textual contents. The int2vector correction illustrates why returning superficially similar metadata may not be sufficient. The client sees a protocol value with a type, then interprets it according to the rules of its driver or ORM.
Cluster behavior accompanies the arithmetic changes
The release adds SQL statement latency graphs and records inter-node round-trip metrics. It also closes inter-node connections on heartbeat timeout and avoids transferring leases or replicas to draining nodes. These changes concern how the distributed system behaves and how operators inspect it.
They do not supply a performance claim about the new decimal implementation. The release's arithmetic message is about changed results and PostgreSQL-compatible rounding. Keeping that message distinct from unrelated query and cluster improvements gives the upgrade a clear semantic consequence, existing DECIMAL expressions now use the replacement implementation and its documented half-away-from-zero default.