BareSQL Portable on BareSQL.com

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.

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.

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.

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.