Case Studies on BareSQL.com

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.

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 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.