The index exists but EXPLAIN shows a sequential scan.
Usually one of three things: the query returns a large fraction of the table so the scan really is cheaper, the types do not match so the index is not applicable, or statistics are stale. ANALYZE the table first, then compare with SET enable_seqscan = off to see what the planner thinks the index would cost.
Users see their own edits disappear after saving. Replica lag?
Almost certainly. Route reads that follow a write by the same user to the primary for a short window, or track the write LSN in the session and wait for the replica to reach it. The general fix is read-your-writes consistency, not lower lag.
I deleted 12M rows and the index is still the same size. Why?
Deleting rows marks them dead but leaves index entries until vacuum reclaims the pages, and even then the pages stay allocated to that index. REINDEX INDEX CONCURRENTLY is what actually returns the space.