Is this the same as the percentage coming back as 0?

No. Integer division turns 3/10 into 0. Division by zero is when the denominator is actually 0 — no rows in that group, or a COUNT of conversions over a COUNT of trials that is zero. One is a silent wrong number; this one errors or goes NULL.

Why did it work last week and fail this week?

A new plan, a region with no signups, or a day with no traffic created a group whose denominator is 0. The SQL did not change. The data did.

What does each database do?

Postgres and SQL Server typically error (division by zero). MySQL often returns NULL for 1/0 in a SELECT. Same query, three failure modes — loud on two engines, blank on one.

NULLIF(denominator, 0) so 0 becomes NULL and the rate is NULL instead of a crash — then COALESCE(..., 0) if you want to display 0%. Or filter out empty groups in HAVING COUNT(*) > 0.

Should empty groups show 0% or be omitted?

Product call. 0% means 'we measured and nothing converted.' Omitting the row means 'no denominator, don't report a rate.' Say which you want. Don't let the database decide by erroring.

SQL Division by Zero | Conversion Rate Error

You ask for conversion rate by plan. It works until Launch has zero trials this month. Postgres returns division by zero. MySQL hands you a NULL rate for that row and looks fine otherwise. The SQL is the same query that worked last week.

The denominator is a count that can be zero

SELECT
  plan,
  COUNT(*) FILTER (WHERE converted) * 100.0 / COUNT(*) AS rate
FROM trials
GROUP BY plan

COUNT(*) is 0 for a plan with no rows in the filtered set — or you divided conversions by COUNT(*) FILTER (WHERE started) and nobody started. That is not integer truncation (3/10 = 0). The divisor is literally zero.

Postgres / SQL Server — usually an error. The whole query dies, not just that group.
MySQL — often NULL for that cell. Easy to miss in a table of other rates.

Same family as SUM over zero rows → NULL: empty data does not become a friendly zero unless you say so.

The guard

SELECT
  plan,
  COALESCE(
    COUNT(*) FILTER (WHERE converted) * 100.0
      / NULLIF(COUNT(*), 0),
    0
  ) AS rate
FROM trials
GROUP BY plan

NULLIF(count, 0) turns a zero denominator into NULL so the division does not explode. COALESCE(..., 0) is optional — only if you want empty groups to display as 0% instead of blank.

Or drop empty groups:

HAVING COUNT(*) > 0

That's the right move when a rate with no trials should not appear at all — pair with HAVING vs WHERE.

How to catch it

If a report that ran yesterday now errors, ask: "which group has COUNT = 0?" A new plan, a new region, or a weekend with no signups is the usual answer. Don't "fix" it by removing GROUP BY.

The prompt that heads this off

When dividing (rates, averages built by hand, per-user ratios), wrap
the denominator in NULLIF(..., 0). If a group can have zero rows, say
whether you want 0%, NULL, or the row omitted (HAVING COUNT(*) > 0).
Don't let one empty plan fail the whole query.

The short version

A conversion rate needs a denominator. One empty group is enough to crash Postgres — or silently blank a MySQL cell. Guard the divide; don't assume every plan had traffic.

Read-only MCP gateway: mcpserver.design.

Related reading: