9 silent-row-loss fixes in 7 days across 7 OSS databases

A pattern: a JavaScript database re-implements four common SQL operators - upper/lower, length/substr, case-insensitive match, range comparison. The implementation looks right. The tests pass. The CI is green. And then the moment a user's data contains the German ß, a fi ligature, an emoji, a Turkish dotted-i, or a CJK Extension B character, the operator silently returns the wrong rows. No error. No log. Just less data than the user expected, or the wrong data.

I've now shipped this exact bug class to seven open-source JavaScript database query layers in seven days. Nine PRs. None of them throw. All of them silently return wrong rows. Here's the streak:

1. 
   PowerSync (#644) - LIKE/range semantics. Merged. Funded a paid 48-hour follow-on sprint.


2. 
   PowerSync (#645) - CAST semantics. Merged.


3. 
   PowerSync (#646) - division by zero. Merged.


4. 
   PowerSync (#647) - json_each over scalar. Merged.


5. 
   PowerSync (#662) - JOIN parsing silently syncs zero rows. Open.


6. 
   PowerSync (#663) - upper/lower ASCII vs Unicode case-fold divergence. Open.


7. 
   PowerSync (#664) - length() UTF-16 code units vs SQLite code points. Open.


8. 
   PowerSync (#665) - substring() splitting surrogate pairs. Open.


9. 
   TanStack DB (#1574) - ASCII case fold in upper/lower/ilike. Open today.

Plus earlier same-class fixes in Rocicorp's Zero, InstantDB, ElectricSQL, Dexie, and RxDB.

The pattern is always the same shape

A JS database re-implements a SQL operator in JavaScript:

// PowerSync sync-rules - before

const upper = { call(value) { return value?.toUpperCase() ?? null } }



// TanStack DB - before

case `upper`: return (data) => {

  const value = arg(data)

  return typeof value === `string` ? value.toUpperCase() : value

}

String.prototype.toUpperCase() is locale-aware and length-changing:

When the JS re-implementation and the source database disagree, the bucket key the client looks up and the bucket key the server wrote silently mismatch. The row doesn't appear on the client. No error fires.

Same pattern for length() - JavaScript's String.prototype.length counts UTF-16 code units, SQLite's length() counts code points. They disagree by 2x on every emoji, CJK Extension B-G character, and ancient script glyph. Same for substring() - JS slices on code units and can return unpaired surrogates. Same for case-insensitive LIKE / ilike - same toLowerCase() length-change problem.

The fix is always the same shape too

Stop calling locale-aware JS string methods on data the database is supposed to be authoritative about. Use ASCII-only case fold loops, iterate by code points (for...of or [...text]), and walk surrogate pairs deliberately.

It's about 30 lines of JS to catch the four common cases. I packaged it:

npm i silentdrop

. Or smaller scope - one specific operator I find a divergence on, repro + fix + PR delivered - $500: https://buy.polar.sh/polar_cl_G0fuUHHZ1tg9E0oe7gluje9gs44l8FAqVnfwS2AJkbw.

Otherwise, npm i silentdrop is free and the first bug it finds will pay you back in the prevented hours of debugging.