Numbers on BareSQL.com

CAST to INTEGER Fails on MySQL and Rounds Differently on SQLite and PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

Turning a price into a whole number with CAST(5.7 AS INTEGER) gives 5 on SQLite and 6 on PostgreSQL and MariaDB. MySQL doesn’t run it at all.

SQLite drops the fraction and PostgreSQL and MariaDB round it. MySQL takes only SIGNED and UNSIGNED as integer types in CAST, and PostgreSQL refuses both. Decimals differ as well: SQLite ignores the scale of CAST(x AS DECIMAL(10, 1)) and keeps every digit, and MySQL and MariaDB read DECIMAL without a precision as DECIMAL(10, 0), a whole number.

Dividing Decimals Gives Six Decimal Places on MySQL and Sixteen on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

Split an invoice of 80.50 three ways and MySQL and MariaDB hand back 26.833333, PostgreSQL 26.8333333333333333 and SQLite a floating point number. Most of the time nobody notices. Then a report that adds the shares back up gets a different total on MySQL than on PostgreSQL.

MySQL and MariaDB give the result of a decimal division four more decimal places than the dividend has (the div_precision_increment setting) and cut it there. PostgreSQL keeps at least 16 significant digits, and SQLite divides as floating point numbers. Shares of an amount and averages of a DECIMAL column then differ in their last digits.

Division by Zero Is NULL on SQLite and MySQL and an Error on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

A report that divides revenue by visits fails on PostgreSQL the first time a page has no visits. On SQLite, MySQL and MariaDB the same row quietly shows NULL.

PostgreSQL stops the whole statement. SQLite, MySQL and MariaDB answer NULL, MySQL and MariaDB with a warning, and in INSERT and UPDATE with an error when the strict mode includes ERROR_FOR_DIVISION_BY_ZERO (the default). The remainder operator % behaves the same way.

Integer Division Drops the Fraction on SQLite and PostgreSQL and Keeps It on MySQL

Mon, 26 Oct 2026 00:00:00 +0000

You write an average as SUM(stock) / COUNT(*), try it on SQLite and get 3. MySQL gives 3.3333 for the same rows. Both are doing what they were built to do, and they disagree about what dividing two integers means.

SQLite and PostgreSQL give an integer result when both sides of / are integers, so 7 / 2 is 3. MySQL and MariaDB always divide as decimals and answer 3.5000. Averages written as SUM(x) / COUNT(*) are where this usually bites: the sum of an integer column is an integer on SQLite and PostgreSQL, so the average loses its fraction there.

LOG With One Argument Is Base 10 on PostgreSQL and the Natural Logarithm on MySQL

Mon, 26 Oct 2026 00:00:00 +0000

A score or a scale built on LOG() shifts when the code moves to another engine, because LOG(100) doesn’t mean the same logarithm everywhere.

LOG(100) is 2 on SQLite and PostgreSQL and 4.605 on MySQL and MariaDB. With two arguments, LOG(b, x) is the logarithm of x to base b on all four. SQLite has LOG, LN, LOG10 and POWER only when it is built with its math functions: the sqlite3 program is by default since version 3.35, and some systems ship it without them.

REAL on PostgreSQL and FLOAT on MySQL Are 4-Byte Floats That Drop Digits

Mon, 26 Oct 2026 00:00:00 +0000

Measurements kept in a REAL column on PostgreSQL, or in a FLOAT column on MySQL or MariaDB, come back with fewer digits than went in. The same type names keep them all on the other engines.

PostgreSQL’s REAL is a 4-byte float, and so is FLOAT on MySQL and MariaDB, while the other engines store 8 bytes for the same name. 1.23456789 comes back as 1.2345679 or 1.23457.

SQLite Keeps DECIMAL Values as Floats and Sums of Prices Pick Up Rounding Errors

Mon, 26 Oct 2026 00:00:00 +0000

A shop keeps its prices in a DECIMAL(10, 2) column and checks that an order’s lines add up to its total. On SQLite that check can fail for an order of 0.10 and 0.20.

PostgreSQL, MySQL and MariaDB keep DECIMAL values exact, so the sum of 0.1 and 0.2 equals 0.3 there. SQLite has no exact decimal type: it stores 0.1 as the nearest binary fraction, the sum is 0.30000000000000004, and the comparison is false.

The Caret Operator Is a Power on PostgreSQL and a Bitwise XOR on MySQL

Mon, 26 Oct 2026 00:00:00 +0000

A growth formula written as rate ^ years works on PostgreSQL. On MySQL and MariaDB it still runs and gives numbers that have nothing to do with growth: 2 ^ 3 is 1 there.

PostgreSQL raises the left side to the power of the right one. MySQL and MariaDB combine the bits of both numbers. SQLite has no ^ operator.