The GIN index is general, the limitation is that the optimizer can only use the index for expressions where the operator is applied directly to the indexed fiel

The GIN index is general, the limitation is that the optimizer can only use the index for expressions where the operator is applied directly to the indexed field. The example in the docs is somewhat unfortunate because it can also be expressed directly on the indexed column using the jsonb containment operator, allowing the index can be used: -- Find documents in which the key "tags" contains key or array element "qui" SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qui"]}'; SQL/JSON path provides much greater expressivity than the containment operator so it allows more complex queries than can be expressed in terms of jsonb containment to be written directly on the indexed column enabling the index to be used. > Taking a look at the most recent docs, it seems jsonb_ops should provide similar index optimization characteristics to the index operations in the extension for the native SQL/JSON Path type. Likely with similar trade offs. Definitely check with jsonb_path_ops too. While it doesn't cover quite as much as jsonb_ops the index is much more compact so queries are often quite a bit faster using it instead of the larger jsonb_ops index.