Posts on BareSQL.com

A Backslash in LIKE Escapes Percent and Underscore Everywhere Except SQLite

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

Searching for the text 50_off with LIKE '50\_off' works on PostgreSQL, MySQL and MariaDB, where the backslash escapes the underscore. SQLite treats the backslash as an ordinary character, and the search finds nothing.

'a_b' LIKE 'a\_b' is true on PostgreSQL, MySQL and MariaDB, where \_ matches an underscore, and false on SQLite, where the pattern asks for a backslash followed by any one character.

A Backslash Is an Escape Character in MySQL Strings and a Plain Character in PostgreSQL

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

A Windows path written as 'C:\temp\new' reads back on MySQL and MariaDB with a tab and a line break in it. PostgreSQL and SQLite keep the backslashes as typed.

'C:\\temp' is C:\\temp, two backslashes, on SQLite and PostgreSQL and C:\temp on MySQL and MariaDB. '\t' is a tab and '\'' a quote there, while PostgreSQL needs its E'...' strings for escapes, which no other engine reads. MySQL’s NO_BACKSLASH_ESCAPES mode makes it read backslashes like the others.

A Quarterly Access Review Finds a New Table of Bank Accounts That Every Role Can Read

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

The shop in this case study is made up: it’s the sample shop database that BareSQL’s tests build, and the outputs are what BareSQL printed. It reviews database access once a quarter. The first review with BareSQL Audit covers every login and ends with a file kept for next time, audit.json.

Three months later the review runs again against that file. The reviewer then reads what changed, with no need to compare two long reports by eye.

A Support View Showed Card Numbers to Every Support Login

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

This case study runs on the sample shop database that BareSQL’s tests build, so the shop is made up, and the outputs are what BareSQL printed. Its support team looks customers up through one view, support.customer_lookup, and has no grant on the customers table itself, which sounds like the careful way to do it.

The view was meant to show a name, an email address and a phone number, enough to help someone who calls in. At some point a column was added to it. The team has two logins, shop_alice and shop_bob. Bob is in the team without inheriting its rights, a setup often taken to mean he can’t read what the team reads.

Adding 1 to a Date Gives the Next Day on PostgreSQL and a Number on MySQL and SQLite

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

due_date + 1 reads like the day after, and on PostgreSQL that is what it gives. On MySQL, MariaDB and SQLite the answer is a plain number.

MySQL and MariaDB turn the date into the number 20240131 and add 1. SQLite turns the text into the number 2024. PostgreSQL adds a day. Subtracting two dates goes the same way: PostgreSQL counts days and MySQL and MariaDB subtract the numbers. INTERVAL arithmetic works on PostgreSQL, MySQL and MariaDB, with different result types, and SQLite has no INTERVAL. PostgreSQL’s usual INTERVAL '1 day', with the unit inside the quotes, works on PostgreSQL only.

Backticks Around Names Work on MySQL and SQLite and Fail on PostgreSQL

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

MySQL examples often quote every name in backticks, as in SELECT `name` FROM `people`. Copied into a PostgreSQL project, the query fails.

`name` is MySQL’s way of quoting a name, and SQLite and MariaDB accept it too. PostgreSQL reads the backtick as a syntax error.

BareSQL Launches With an Access Audit for PostgreSQL and a Portability Check for SQL

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

BareSQL is a free, open-source command-line program with two tools in it. BareSQL Audit lists every column each PostgreSQL login can read, with the route that gets it there, and marks the ones that hold personal data. BareSQL Portable finds the SQL that fails or answers differently on SQLite, PostgreSQL, MySQL and MariaDB. Version 0.1.0 is the first release.

Who can read the customers’ email addresses? In a PostgreSQL database the answer is spread over role memberships, grants made years ago, views that read tables with their owner’s rights, default privileges and row security policies. Working it out by hand means an afternoon with the system catalogs, and the answer is out of date the next time someone runs a GRANT. BareSQL Audit logs in, reads the catalogs inside a read-only transaction and writes the answer down: a report for people and a JSON file for the next audit to be compared with.

CAST to CHAR Cuts a Value to One Character on PostgreSQL

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

CAST(order_id AS CHAR) looks like a safe way to turn a number into text. On PostgreSQL CHAR without a length means one character, so order 123 comes back as '1'.

PostgreSQL reads CHAR without a length as CHAR(1) and cuts the value to fit. With a length, CHAR(10), it pads the value with spaces. MySQL accepts CHAR in CAST but neither VARCHAR nor TEXT, and MariaDB accepts VARCHAR but not TEXT.

CAST to DATE Returns the Number 2024 on SQLite Because It Has No Date Type

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

Filtering orders with CAST(created_at AS DATE) = '2024-05-06' works on PostgreSQL, MySQL and MariaDB. SQLite has no date type, turns the CAST into a number and keeps only the year, so the filter never matches.

SQLite keeps dates as text or numbers and reads a CAST to DATE, DATETIME or TIMESTAMP as a conversion to a number, which keeps only the leading digits. MySQL and MariaDB also refuse CAST(x AS TIMESTAMP), and PostgreSQL refuses DATETIME.

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.

CHAR Columns Come Back Padded With Spaces on PostgreSQL

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

An order status kept in a CHAR(10) column compares as expected in SQL on every engine. In the application code, though, a check for paid orders fails on PostgreSQL alone.

A CHAR(5) column holding 'a' returns 'a ' on PostgreSQL. Comparisons there ignore the padding, so WHERE c = 'a' still matches, but the spaces reach the application and CONCAT. MySQL and MariaDB strip trailing spaces when they read CHAR values, and SQLite does not apply the length at all.

Column Types Like DATETIME and BYTEA Exist on Some SQL Engines Only

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

A schema with DATETIME and JSONB columns runs on SQLite without complaint. Both types fail on at least one of the other engines.

SQLite accepts nearly any type name, so a schema that works there can still fail elsewhere. Each type in the table was used in a CREATE TABLE on all four engines.

Columns Missing From GROUP BY Work on SQLite and MariaDB and Fail on PostgreSQL and MySQL

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

SELECT customer_id, name, SUM(total) FROM orders GROUP BY customer_id is the kind of query that runs for years on SQLite or MariaDB. Point the same code at PostgreSQL or MySQL and it stops with an error, because name is neither grouped nor summed.

SELECT a, b FROM t GROUP BY a asks for one b per group without saying which. SQLite and MariaDB pick one (MariaDB’s default mode leaves out ONLY_FULL_GROUP_BY). PostgreSQL and MySQL stop with an error, unless the grouped column is the table’s primary key, which fixes every other column of that table.

Comparing a Boolean With 1 Works on MySQL and SQLite and Fails on PostgreSQL

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

WHERE active = 1 is the usual way to test a flag on MySQL, and SQLite and MariaDB read it the same way. Moved to PostgreSQL, the query stops with an error.

On SQLite, MySQL and MariaDB a boolean is the number 0 or 1, and TRUE is another way to write 1. PostgreSQL has a real boolean type with no automatic conversion from integers, so code written for MySQL that compares flags with 1 stops there.

Comparing a Text Column With the Number 0 Matches Codes Like abc on MySQL and Fails on PostgreSQL

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

Product codes are text, and a query that forgets the quotes, WHERE code = 0, still runs on MySQL and MariaDB. There it returns codes that have nothing to do with 0.

MySQL and MariaDB turn the text into a number, and text that does not start with digits becomes 0, so WHERE code = 0 finds every code like 'abc'. SQLite compares the number as text and finds nothing. PostgreSQL refuses to compare character varying with integer. '1' = 1 trips over the same thing in another way: false on SQLite, true on the other three.

CONCAT With a NULL Argument Returns NULL on MySQL and Skips It on PostgreSQL

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

A customer list built with CONCAT(first_name, ' ', last_name) looks complete on PostgreSQL and SQLite. Moved to MySQL or MariaDB, the same query returns NULL for some customers.

A person without a last name comes out as 'Ann ' on SQLite and PostgreSQL and as NULL on MySQL and MariaDB, so a list of names quietly loses entries there. CONCAT_WS skips NULL arguments on all four engines.

COUNT DISTINCT With Two Columns Works on MySQL and Fails on PostgreSQL and SQLite

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

COUNT(DISTINCT customer_id, product_id) counts the distinct pairs on MySQL and MariaDB. SQLite and PostgreSQL take a single expression in COUNT(DISTINCT ...) and refuse it.

SQLite reports the wrong number of arguments and PostgreSQL a missing function.

DISTINCT ON Works on PostgreSQL Only

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

DISTINCT ON (customer_id) is a neat way to keep each customer’s latest order on PostgreSQL, and none of the other three engines has it.

SQLite, MySQL and MariaDB report a syntax error. Window functions say the same thing on all four (SQLite 3.25, MySQL 8.0 and MariaDB 10.2 and later).

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.

Double Dash Comments Need a Space After Them on MySQL and MariaDB

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

In a line like SELECT price --discount, left over from debugging, SQLite and PostgreSQL read --discount as a comment. MySQL and MariaDB add the discount to the price instead.

SQLite and PostgreSQL treat every -- as the start of a comment. MySQL and MariaDB need a space, a tab or a line break after the dashes; otherwise they are two minus signs.

Double Quotes Name a Column on PostgreSQL and Make a String on MySQL

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

A query copied from PostgreSQL that puts a column name in double quotes runs on MySQL without an error, and never reads the column.

Standard SQL quotes names with double quotes, and SQLite and PostgreSQL follow it. MySQL and MariaDB read "..." like '...' unless the ANSI_QUOTES mode is on: the query still runs and returns the same text on every row. SQLite also turns a double-quoted word into a string when no column has that name.

FETCH FIRST ROWS ONLY Works on PostgreSQL and MariaDB and Fails on MySQL and SQLite

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

FETCH FIRST 10 ROWS ONLY is the standard way to ask for the top ten, and PostgreSQL and MariaDB accept it. SQLite and MySQL refuse the query.

MariaDB added FETCH FIRST in version 10.6. SQLite and MySQL know only LIMIT, and they refuse OFFSET n ROWS for the same reason.

FULL OUTER JOIN Works on PostgreSQL and SQLite and Fails on MySQL and MariaDB

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

Matching two lists, such as invoices and payments, to see what is missing on either side calls for a FULL OUTER JOIN. PostgreSQL and SQLite run it, and MySQL and MariaDB refuse it.

MySQL and MariaDB have LEFT and RIGHT joins only. SQLite added RIGHT and FULL joins in version 3.39.

GREATEST Skips NULL on PostgreSQL and Returns NULL on MySQL

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

GREATEST(sale_price, list_price) picks the larger of two prices. When one of them is NULL, PostgreSQL still picks the other price, and no other engine does.

GREATEST(1, NULL) is 1 on PostgreSQL and NULL on MySQL and MariaDB. SQLite has the same idea under the names MAX(a, b) and MIN(a, b) with two or more arguments; they return NULL when any argument is NULL, and the other engines read MAX and MIN as aggregates.

Hash Comments Work on MySQL and MariaDB and Become an Operator on PostgreSQL

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

MySQL and MariaDB skip everything from a # to the end of the line. On SQLite and PostgreSQL that # is still part of the statement.

Scripts written for the mysql client often use # comments. SQLite stops with a syntax error. On PostgreSQL # is a bitwise exclusive or, so the rest of the line becomes part of the expression.

How BareSQL Audit Finds Every Column a PostgreSQL Login Can Read

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

PostgreSQL keeps the answer to “who can read this column?” in many places. Grants sit in access lists on tables and on single columns. Role memberships nest, and since PostgreSQL 16 each one says separately whether its rights are inherited and whether SET ROLE is allowed. Views read their tables with their owner’s rights unless they say otherwise, row security policies filter what a table hands out, and default privileges hand out tables that don’t exist yet.

How BareSQL Audit Was Tested Against Planted Leaks on Six PostgreSQL Versions

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

An access audit can be wrong in two directions. If it misses a route, a leak goes unnoticed because the report said all was well. If it invents one, people spend a day chasing access that was never there and stop trusting the report. So BareSQL Audit is tested against databases where every right answer is known in advance, and against the one judge that can’t be argued with, the PostgreSQL server itself.

How BareSQL Portable Finds SQL That Answers Differently on Four Engines

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

Most SQL that fails on another engine fails loudly, with a syntax error on the first run. The expensive kind runs everywhere and answers differently. On the sample shop’s products, SUM(stock) / COUNT(*) is 3 on SQLite and PostgreSQL and 3.3333 on MySQL. ORDER BY last_order puts the customers who never ordered first on three engines and last on PostgreSQL. A search with LIKE finds Ann on SQLite and misses her on PostgreSQL, and '1' = 1 is false on SQLite and true on the other three. None of these raise an error.

How BareSQL Portable Was Tested on Four Real Database Engines

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

Every message baresql lint prints is a claim about four database engines. “GROUP_CONCAT() works on SQLite, MySQL and MariaDB; PostgreSQL refuses it.” Claims like that go stale, since engines add and drop functions between versions. Written from memory, a catalog of differences would be wrong in places on the day it shipped. So the answers BareSQL Portable quotes are the ones the engines gave when the catalog ran. A few messages also name the release in which an engine changed, such as SQLite 3.44 for CONCAT(), and those come from the engines’ release notes.

INSERT IGNORE Becomes INSERT OR IGNORE on SQLite and ON CONFLICT DO NOTHING on PostgreSQL

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

Loading a file of events that may hold rows you already have calls for an insert that skips duplicates. MySQL and MariaDB spell it INSERT IGNORE and SQLite INSERT OR IGNORE, while PostgreSQL and SQLite take ON CONFLICT DO NOTHING.

Each form skips rows that would break a unique key, and each fails on the engines that use another one. INSERT IGNORE also hides other errors on MySQL and MariaDB, such as values that do not fit the column.

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.

LENGTH Counts Bytes on MySQL and MariaDB and Characters on PostgreSQL and SQLite

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

A check that a name is at most 20 characters long, written with LENGTH(name), lets 20 letters through on SQLite and PostgreSQL. MySQL and MariaDB count bytes instead, so a name with accents reaches the limit sooner.

In UTF-8 a letter outside A to Z takes two to four bytes. MySQL and MariaDB count characters with CHAR_LENGTH, which SQLite lacks. Length checks and cut-offs drift apart on names and addresses with accents.

LIKE Ignores Letter Case on SQLite and MySQL and Respects It on PostgreSQL

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

A search box that runs WHERE name LIKE 'ann%' finds Ann on SQLite, MySQL and MariaDB. On PostgreSQL it misses her, because LIKE there compares letters exactly.

SQLite’s LIKE ignores case for the letters A to Z only. MySQL and MariaDB follow the collation, which ignores case by default. PostgreSQL’s LIKE is exact; its ILIKE ignores case, and exists on PostgreSQL only.

LIMIT With a Comma Works on MySQL and SQLite and Fails on PostgreSQL

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

Paging code written for MySQL often says LIMIT 20, 10: skip 20 rows, return 10. SQLite and MariaDB read it the same way. PostgreSQL refuses it.

In LIMIT a, b the first number is the offset and the second the count, the reverse of the order in which LIMIT ... OFFSET reads.

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.

MySQL and MariaDB on Linux Treat Table Names as Case Sensitive

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

Code that creates a table as Users and later reads users works on SQLite and PostgreSQL. On MySQL or MariaDB running on Linux it fails, since users is another table that doesn’t exist, while the same code on a Mac works, which makes the bug easy to miss.

MySQL and MariaDB keep each table in files named after it, and file names on Linux are case-sensitive (lower_case_table_names = 0, the default there). On Windows and macOS the default makes names case-insensitive. SQLite and PostgreSQL ignore case in unquoted names.

MySQL and MariaDB Refuse LIMIT Inside an IN Subquery

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

Finding the customers behind the ten latest orders with WHERE id IN (SELECT customer_id FROM orders ORDER BY created_at DESC LIMIT 10) works on SQLite and PostgreSQL. MySQL and MariaDB refuse it.

Both report that this version doesn’t yet support 'LIMIT & IN/ALL/ANY/SOME subquery'. LIMIT is fine in a subquery used as a table and in one that returns a single value.

MySQL Compares Text Without Regard to Letter Case and PostgreSQL Compares It Exactly

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

Sign-ups as ann@example.com and Ann@example.com are two users on PostgreSQL and SQLite. On MySQL and MariaDB a unique key on the email column refuses the second sign-up.

The default collations of MySQL and MariaDB ignore case and accents, so 'abc' = 'ABC' and 'e' = 'é' are true there and false on SQLite and PostgreSQL. The same goes for joins, GROUP BY, DISTINCT and unique keys: two values that differ only in case count as one on MySQL and as two elsewhere. Whether an answer changes depends on the data, so lint reports this as information.

MySQL Refuses a Key on a TEXT Column Without a Prefix Length

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

A TEXT column as a primary key is ordinary on SQLite and PostgreSQL. MySQL and MariaDB refuse it, and MySQL refuses a plain index or unique key on TEXT as well.

SQLite and PostgreSQL index TEXT columns as they are. MySQL wants a prefix length, INDEX (x(100)), which the others reject. MariaDB 10.4 and later accept plain indexes and unique keys on TEXT columns.

MySQL Refuses a Plain DEFAULT Value on TEXT Columns

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

A notes column declared as TEXT DEFAULT '' works on SQLite, PostgreSQL and MariaDB. MySQL refuses the CREATE TABLE.

MySQL 8.0.13 and later accept a default written as an expression in parentheses, DEFAULT ('a'), which the other three engines accept as well.

MySQL Refuses an UPDATE Whose Subquery Reads the Same Table

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

Marking rows with UPDATE t SET flag = 1 WHERE id IN (SELECT id FROM t WHERE ...) works on SQLite, PostgreSQL and MariaDB. MySQL refuses an UPDATE or DELETE whose subquery reads the table being changed.

MySQL says you can’t specify target table 't' for update in FROM clause. MariaDB lifted the limit in version 10.3.2. A subquery used as a table works on MySQL too, because MySQL then computes its rows before it changes anything.

MySQL Refuses CREATE INDEX IF NOT EXISTS

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

Migrations that may run twice often say CREATE INDEX IF NOT EXISTS, and SQLite, PostgreSQL and MariaDB accept it. MySQL stops the migration with a syntax error.

MySQL accepts IF NOT EXISTS for tables and databases, and not for indexes.

MySQL Refuses INSERT RETURNING While PostgreSQL and SQLite Accept It

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

INSERT ... RETURNING id hands back the new row’s id in the same round trip on SQLite, PostgreSQL and MariaDB. MySQL has no RETURNING and refuses the statement.

SQLite added RETURNING in version 3.35, and MariaDB in 10.5 for INSERT and DELETE (MariaDB refuses it on UPDATE). Each engine also has its own function for the last generated id: LAST_INSERT_ID() on MySQL and MariaDB, last_insert_rowid() on SQLite and lastval() on PostgreSQL.

MySQL Table Options Like ENGINE and CHARSET Fail on PostgreSQL and SQLite

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

A MySQL schema ends its CREATE TABLE statements with options such as ENGINE=InnoDB DEFAULT CHARSET=utf8mb4. SQLite and PostgreSQL refuse the statement at the first option.

Dumps made with mysqldump carry these options on every table. SQLite’s own options, WITHOUT ROWID and STRICT, fail on the other three engines in the same way.

No Auto Increment Column Syntax Works on Every SQL Engine

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

A schema meant for several engines needs ids that number themselves, and no single way of asking for that works on all four. SERIAL comes closest, and on SQLite it fails without a word.

AUTO_INCREMENT belongs to MySQL and MariaDB, AUTOINCREMENT to SQLite, and GENERATED BY DEFAULT AS IDENTITY to PostgreSQL. SERIAL is PostgreSQL’s as well, and MySQL and MariaDB accept it as BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE. SQLite accepts any type name, so SERIAL is only a name there and the column stays NULL: SQLite numbers rows for a column declared INTEGER PRIMARY KEY and nothing else.

NULL Sorts First on SQLite and MySQL and Last on PostgreSQL

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

Sort customers by the date of their last order and the ones who never ordered come first on SQLite, MySQL and MariaDB and last on PostgreSQL. The first page of the same report shows different people.

The standard leaves the place of NULL in ORDER BY to the engine. PostgreSQL treats NULL as larger than every value, the others as smaller, and descending order turns both around. Paged results change when the column holds NULL, and so do window functions such as ROW_NUMBER() OVER (ORDER BY x).

NULLS FIRST and NULLS LAST Fail on MySQL and MariaDB

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

ORDER BY shipped_at NULLS LAST is the tidy way to put unshipped orders at the end on PostgreSQL and SQLite. MySQL and MariaDB have no such syntax and refuse the query.

SQLite added them in version 3.30. MySQL and MariaDB have no syntax for choosing where NULL sorts.

Only SQLite Lets WHERE Use a Name From the Select List

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

A query that names price * quantity as total in the select list and then filters on total in WHERE runs on SQLite. PostgreSQL, MySQL and MariaDB refuse it, since the table has no column named total.

WHERE is worked out before the select list, so in standard SQL the y of SELECT x * 2 AS y does not exist yet. SQLite looks it up anyway.

PostgreSQL Refuses Select List Names in HAVING

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

A report of repeat customers names its count of orders n in the select list and filters on that name in HAVING. SQLite, MySQL and MariaDB run it, and PostgreSQL refuses the query.

PostgreSQL looks up names in HAVING among the table’s columns only, so HAVING n > 1 fails when n is the name of COUNT(*).

PostgreSQL Returns Column Names in Lower Case Unless You Quote Them

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

SELECT SUM(amount) AS Total gives a column named Total on SQLite, MySQL and MariaDB. PostgreSQL calls it total.

SQLite, MySQL and MariaDB return names as written. PostgreSQL folds unquoted names to lower case, in aliases and in CREATE TABLE alike, so code that reads columns by name (row["Total"]) finds nothing on PostgreSQL.

Queries That Pass Their Tests on SQLite and Break on PostgreSQL in Production

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

This case study uses a demo project in BareSQL’s code repository: a made-up booking app with a schema of two tables and eleven queries, written the way an app tested on SQLite tends to write them. Its test suite stays fast the usual way. Each test builds the schema in an in-memory SQLite database, runs the app’s queries and throws the database away.

Production runs on PostgreSQL. Every query passes every test, and the question is how many of them do the same thing in production. The outputs below are what BareSQL printed.

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.

SQL Functions That Exist on Some Engines Only and What to Write Instead

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

IFNULL, NOW, LEFT and STRING_AGG are everyday functions, and each one is missing on at least one of SQLite, PostgreSQL, MySQL and MariaDB. BareSQL Portable knows 78 functions like these.

Each function in the table was called on all four engines, and the table shows where the call ran and what to write instead.

SQL Operators That Exist on Some Engines Only and What to Write Instead

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

Operators such as ::, ILIKE, DIV and XOR belong to one or two engines, and the others refuse them. BareSQL Portable knows 16 operators like these.

Each operator in the table was used on all four engines, and the table shows where it ran and what to write instead.

SQLite Has No CREATE OR REPLACE VIEW

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

CREATE OR REPLACE VIEW lets a migration change a view in one step on PostgreSQL, MySQL and MariaDB. On SQLite the statement is a syntax error.

SQLite can only drop a view and create it again.

SQLite Has No TRUNCATE Statement

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

Test setups often empty their tables with TRUNCATE TABLE between runs. PostgreSQL, MySQL and MariaDB have it, and SQLite refuses it.

SQLite empties a table quickly with a DELETE FROM t that has no WHERE clause. On MySQL and MariaDB, TRUNCATE also resets the AUTO_INCREMENT counter, which DELETE leaves alone.

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.

SQLite LOWER and UPPER Change Only the Letters A to Z

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

Searching names with LOWER(name) = LOWER('Émile') works on PostgreSQL, MySQL and MariaDB. On SQLite, LOWER changes only A to Z, so É stays É and a stored émile never matches.

SQLite folds case for ASCII letters only, and so do its LIKE and COLLATE NOCASE, unless it is built with the ICU extension, as some systems ship it. Comparisons that use LOWER() to ignore case work on the other engines and fail on SQLite for names like Émile or Ødegaard.

SQLite Stores Text in INTEGER Columns and Ignores VARCHAR Lengths

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

A test suite on SQLite passes with a quantity of 'abc', or 'Germany' in a VARCHAR(2) country column. PostgreSQL, MySQL and MariaDB refuse both values, so the bug shows up in production instead.

Column types on SQLite are preferences: a value that does not fit is stored as it is, and lengths are never checked. Tests that run on SQLite then pass with data the production engine rejects. SQLite’s STRICT tables (version 3.37 and later) check types but not lengths, and the other engines do not accept the STRICT keyword.

SUBSTR From Position 0 Returns Text on SQLite and PostgreSQL and Nothing on MySQL

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

Code ported from a language that counts from 0 often ends up with SUBSTR(code, 0, 3). SQLite and PostgreSQL return the first two characters. MySQL and MariaDB return an empty string.

Positions start at 1. SQLite and PostgreSQL count position 0 as part of the requested length, while MySQL and MariaDB return nothing for a start of 0. Negative starts differ as well: SQLite, MySQL and MariaDB count them from the end, and PostgreSQL counts them before the first character.

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.

The Double Pipe Operator Joins Text on PostgreSQL and SQLite and Means OR on MySQL

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

Code that builds labels with first_name || ' ' || last_name works on PostgreSQL and SQLite. Move it to MySQL or MariaDB and every label comes back as 0, with no error to say why.

The SQL standard joins strings with ||, and SQLite and PostgreSQL follow it. MySQL and MariaDB read || as a logical OR unless the server runs in the PIPES_AS_CONCAT mode, so both strings are turned into numbers and the answer is 0. The warnings they give for it seldom reach the application.

UPDATE With a Join Needs Different Syntax on MySQL and PostgreSQL

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

Copying prices from a staging table with a join takes UPDATE ... FROM on SQLite and PostgreSQL and UPDATE ... JOIN on MySQL and MariaDB, and neither runs on all four.

The engines use different syntax for changing rows based on another table. DELETE differs the same way: DELETE ... USING on PostgreSQL, DELETE t FROM t JOIN ... on MySQL and MariaDB.

Upsert Needs ON CONFLICT on PostgreSQL and ON DUPLICATE KEY UPDATE on MySQL

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

Saving a setting that may or may not exist yet takes one statement on every engine, though not the same one on all four. SQLite and PostgreSQL use ON CONFLICT ... DO UPDATE, MySQL and MariaDB ON DUPLICATE KEY UPDATE.

REPLACE INTO works on SQLite, MySQL and MariaDB, but it deletes the old row and inserts a new one, which fires delete triggers and resets the columns the statement leaves out. Of these four engines, MERGE exists on PostgreSQL 15 and later only.

VARCHAR Without a Length Fails on MySQL and MariaDB

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

Schemas written for PostgreSQL often declare names and notes as plain VARCHAR, with no length. MySQL and MariaDB refuse that CREATE TABLE, since they want a length on every VARCHAR column.

PostgreSQL reads VARCHAR without a length as text of any length, and SQLite ignores lengths anyway.

What an AI Support Agent Could Read Before Its Database Login Went Live

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

This case study runs on the sample multi-tenant database that BareSQL’s tests build. The software company in it is made up: it runs one PostgreSQL database for all its customers, the tenants, and row security keeps each tenant’s rows apart. Every output below is what BareSQL printed.

The support team wants an AI agent to answer tickets, so the agent gets a login of its own, saas_agent, in the saas_support group that support’s views are granted to. The views were written for people, months ago, and nobody remembers exactly what they return. So before the login goes live, the team audits that one login.

What Changed in the Answers When a MySQL App Moved to PostgreSQL

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

This case study uses a demo project in BareSQL’s code repository: a made-up invoicing app that has run on MySQL for years and is moving to PostgreSQL. The project holds the app’s MySQL schema, the same schema rewritten for both engines with some data, and eleven queries as the app ran them on MySQL. The outputs below are what BareSQL printed.

The plan sounds simple: rewrite the schema and fix whatever PostgreSQL refuses. The trouble is in the queries PostgreSQL doesn’t refuse. They run and return rows, and some of the rows are different.

What the Bare in BareSQL Stands For

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

BareSQL is one small program with two tools in it, and the name had to fit both. Bare does that by meaning two things at once: access laid bare, and SQL stripped down to the part every engine agrees on.

The first sense belongs to BareSQL Audit. To lay something bare is to take the covers off and show what’s underneath. In a PostgreSQL database the covers are the layers between a login and a column: roles inside roles, grants made years ago to a group nobody remembers, views that read tables with their owner’s rights, functions that run as someone else. The audit takes those layers apart and lists, for each login, every column it can read and the route that gets it there.