For example, it supports proper ALTER TABLE which doesn't force you to recreate tables and copy data around when you go beyond the most trivial use cases.

This is pretty much the only discussion I've found on this site:

https://news.ycombinator.com/item?id=22155260

For general applications, I prefer to use Rational representation for decimals (Rat or FatRat) and Allomorphs (RatStr, FatRatStr) to maintain a literal representation like this https://raku.land/zef:librasteve/FatRatStr.

So instead of suffering the penalties of

bytes -> BigDecimal (with validation of course)

you thought it's better to add more construction steps in the form of

bytes -> Decimal32 (validation included) -> Big Decimal?

Do you know what kind of performance overhead this entails for your JDBC driver? Because the latter looks roughly about twice as slow, depending on the complexity of your validation code.