Postgres using index locally but not in production - postgresql

Question

When running a query locally, EXPLAIN shows an index being used, but in production, it's not being used.
The index in question is on a JSONB column.
I've rebuilt the indexes in production to see if that was the issue, but it didn't make a difference.
How can I debug (or fix) production not using the indexes properly?
Here's the DDL of the table and its indices.
-- Table Definition ----------------------------------------------
CREATE TABLE tracks (
id BIGSERIAL PRIMARY KEY,
album_id bigint REFERENCES albums(id),
artist_id bigint REFERENCES artists(id),
duration integer,
explicit boolean,
spotify_id text,
link text,
name text,
popularity integer,
preview_url text,
created_at timestamp without time zone NOT NULL,
updated_at timestamp without time zone NOT NULL,
audio_features jsonb,
lyrics text,
lyrics_last_checked_at timestamp without time zone,
audio_features_last_checked timestamp without time zone
);
-- Indices -------------------------------------------------------
CREATE UNIQUE INDEX tracks_pkey ON tracks(id int8_ops);
CREATE INDEX index_tracks_on_album_id ON tracks(album_id int8_ops);
CREATE INDEX index_tracks_on_artist_id ON tracks(artist_id int8_ops);
CREATE INDEX index_tracks_on_spotify_id ON tracks(spotify_id text_ops);
CREATE INDEX index_tracks_on_explicit ON tracks(explicit bool_ops);
CREATE INDEX index_tracks_on_lyrics_last_checked_at ON tracks(lyrics_last_checked_at timestamp_ops);
CREATE INDEX index_tracks_on_audio_features ON tracks USING GIN (audio_features jsonb_ops);
CREATE INDEX index_tracks_on_audio_features_energy ON tracks(((audio_features ->> 'energy'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_tempo ON tracks(((audio_features ->> 'tempo'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_key ON tracks(((audio_features ->> 'key'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_danceability ON tracks(((audio_features ->> 'danceability'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_acousticness ON tracks(((audio_features ->> 'acousticness'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_speechiness ON tracks(((audio_features ->> 'speechiness'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_instrumentalness ON tracks(((audio_features ->> 'instrumentalness'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_valence ON tracks(((audio_features ->> 'valence'::text)::numeric) numeric_ops);
CREATE INDEX index_tracks_on_audio_features_last_checked ON tracks(audio_features_last_checked timestamp_ops);
Here's the query I'm running.
EXPLAIN ANALYZE SELECT "tracks".* FROM "tracks" WHERE ((audio_features ->> 'speechiness')::numeric between 0.1 and 1.0)
Here's the output locally.
Bitmap Heap Scan on tracks (cost=209.20..2622.49 rows=5943 width=616) (actual time=23.510..179.007 rows=5811 loops=1)
Recheck Cond: ((((audio_features ->> 'speechiness'::text))::numeric >= 0.1) AND (((audio_features ->> 'speechiness'::text))::numeric <= 1.0))
Heap Blocks: exact=1844
-> Bitmap Index Scan on index_tracks_on_audio_features_speechiness (cost=0.00..207.72 rows=5943 width=0) (actual time=21.463..21.463 rows=5999 loops=1)
Index Cond: ((((audio_features ->> 'speechiness'::text))::numeric >= 0.1) AND (((audio_features ->> 'speechiness'::text))::numeric <= 1.0))
Planning Time: 10.248 ms
Execution Time: 179.460 ms
And here's the output in production.
Gather (cost=1000.00..866366.71 rows=607073 width=1318) (actual time=0.486..100252.108 rows=606680 loops=1)
Workers Planned: 4
Workers Launched: 3
-> Parallel Seq Scan on tracks (cost=0.00..804659.41 rows=151768 width=1318) (actual time=0.211..99938.152 rows=151670 loops=4)
Filter: ((((audio_features ->> 'speechiness'::text))::numeric >= 0.1) AND (((audio_features ->> 'speechiness'::text))::numeric <= 1.0))
Rows Removed by Filter: 731546
Planning Time: 3.029 ms
Execution Time: 100292.766 ms

Answer 1

The data are quite different in both databases, so it is not surprising if the same query is executed differently.
The production query returns more than 17% of the rows in the table, which is obviously so much that PostgreSQL thinks it cheaper to perform a sequential scan.
For test purposes, you can set enable_seqscan to off in your session, run the query again and check if PostgreSQL was right.
If you didn't select all columns from the table, but only columns that are indexed, and the table has been vacuumed recently, you might get an index only scan which would be much faster.