perf: legacy @cipherstash/drizzle has the same bare-equality bug as @cipherstash/stack/drizzle

[coderdan]

Summary

While fixing #421 in @cipherstash/stack/drizzle (#425), the same bug exists verbatim in the older @cipherstash/drizzle/pg package. Customers still consuming the legacy package seq-scan every encrypted equality lookup on Supabase.

Evidence

packages/drizzle/src/pg/operators.ts:731:

return operator === 'eq' ? eq(left, encrypted) : ne(left, encrypted)

Identical structure for inArray / notInArray further down (OR/AND chains of eq / ne).

The fix is the same wrap that landed in #425:

const op = sql.raw(operator === 'eq' ? '=' : '<>')
return sql`eql_v2.hmac_256(${left}) ${op} eql_v2.hmac_256(${bindIfParam(encrypted, left)})`

…and the analogous change for the array operators.

Decision needed

• If @cipherstash/protect + @cipherstash/drizzle are still supported alongside @cipherstash/stack, port the fix and ship a patch release.
• If they're EOL, document the migration path and close as won't-fix.

The bench in packages/bench doesn't currently exercise the legacy path (it imports through @cipherstash/stack/drizzle only — that was an explicit decision when the bench was scoped). Adapter could be added if we want CI coverage of the legacy path.

Related

• perf: Drizzle eq/ne/inArray emit bare equality, bypassing hmac functional indexes #421 — original bug report (against the legacy package's evidence).
• perf(stack/drizzle): wrap eq/ne/inArray/notInArray in eql_v2.hmac_256(...) #425 — the fix in @cipherstash/stack/drizzle.