Is this the same as the NULL filter post?

Opposite direction. != and NOT IN drop rows because NULL is unknown. Soft delete is extra rows: the model never mentions deleted_at, so tombstones count as live customers.

What if we hard-delete?

Then this bug cannot happen. Most Rails/Laravel/Prisma apps do not hard-delete. Look for deleted_at, discarded_at, archived_at, is_deleted, or a status that includes cancelled.

Why doesn't the AI see the column?

It skipped describe_table and guessed FROM customers. The name is not in the question, so it never appears in the WHERE. Same skip as guessing column names.

Does a status = 'active' filter fix it?

Only if every tombstone also changed status. Many apps leave status as it was and only stamp deleted_at. Filter both if both exist, and ask which one the product actually uses.

What about cancelled subscriptions vs deleted users?

Different columns, same shape. cancelled_at IS NULL, status != 'canceled', and deleted_at IS NULL are three questions. Pick the one the dashboard uses before you compare numbers.

Soft Delete deleted_at Forgotten | SQL Filter

You ask for "how many customers do we have." The AI returns 14,200. The admin UI says 11,800. No join, no OR, no EXTRACT month. The extra 2,400 rows have deleted_at set. They are still in the table. The model never filtered them.

Soft delete is a column, not a DELETE

-- what the model writes
SELECT COUNT(*) FROM customers

-- what the app's default scope writes
SELECT COUNT(*) FROM customers WHERE deleted_at IS NULL

Rails (acts_as_paranoid, Discard), Laravel (SoftDeletes), Prisma (deletedAt), and a lot of hand-rolled schemas never remove the row. They stamp deleted_at / discarded_at / archived_at / is_deleted. The live UI applies that scope on every query. A chat that only saw the table name does not.

Variants that smell the same:

-- boolean flag, often 0/1 not true/false
WHERE is_deleted = false

-- status that includes a tombstone the English ignored
WHERE status NOT IN ('deleted', 'archived', 'merged')

-- subscriptions: cancelled is not deleted
WHERE cancelled_at IS NULL

Boolean mismatch ('f' vs false vs 0) stacks on top of is_deleted. Empty string vs NULL stacks if someone stored '' instead of a timestamp.

This is an over-count. The NULL filter post is an under-count. Don't mix them.

How to catch it

describe_table customers
List columns that look like deleted_at, discarded_at, archived_at,
is_deleted, cancelled_at, status.
COUNT(*) vs COUNT(*) WHERE deleted_at IS NULL.
If they differ, the dashboard is using the second one.

If describe_table shows no such column, check a status enum and a related subscriptions table before you trust COUNT(*).

The prompt that heads this off

Before counting people, orders, or orgs, describe_table and look for
deleted_at / discarded_at / archived_at / is_deleted / cancelled_at.
Default to the same scope the app UI uses (usually deleted_at IS NULL).
Show both counts if you are not sure which I mean.

The short version

"How many customers" in English means live ones. COUNT(*) means every row the table still holds. If the product soft-deletes, those are not the same number until you add deleted_at IS NULL.

Read-only MCP gateway: mcpserver.design.

Related reading: