O operador PostgreSQL JSONB @> é igual a ->''=?

Eu criei um pequeno teste para verificar isso:

CREATE TABLE jsonb_test (id serial, data jsonb);

Em seguida, inseri alguns dados gerados:

INSERT INTO jsonb_test (data) 
SELECT row_to_json(x.*)::jsonb 
  FROM (SELECT i AS bla, 
               ARRAY[i, i+1, i+2] AS foo, 
               ARRAY[('v' || i::text, i), ('v' || (i * 10)::text, i)] AS bar
          FROM generate_series(1,100000) t(i)
       ) x;

Vamos encontrar algo lá ( versão 1 ):

SELECT * FROM jsonb_test WHERE data @> '{"bla": 545}'::jsonb;

O plano de execução parece

 Seq Scan on jsonb_test  (cost=0.00..7604.89 rows=369 width=36) (actual time=0.425..47.600 rows=1 loops=1)
   Filter: (data @> '{"bla": 545}'::jsonb)
   Rows Removed by Filter: 99999
   Buffers: shared hit=2997 dirtied=676
 Planning time: 0.078 ms
 Execution time: 47.692 ms

Se eu fizer o mesmo com a outra versão ( versão 2 ) que você propõe (com o operador alterado de ->para ->>, acho que você quis dizer isso):

SELECT * FROM jsonb_test WHERE data ->> 'bla' = '545';

eu recebo um plano como

 Seq Scan on jsonb_test  (cost=0.00..8526.47 rows=1843 width=36) (actual time=0.613..34.657 rows=1 loops=1)
   Filter: ((data ->> 'bla'::text) = '545'::text)
   Rows Removed by Filter: 99999
   Buffers: shared hit=2997
 Planning time: 0.116 ms
 Execution time: 34.727 ms

Executando-os repetidamente, não vejo diferença significativa entre os tempos de execução. Não é de admirar - a operação cara aqui é a varredura sequencial, enquanto as duas condições de filtro diferentes não devem ser muito diferentes a esse respeito.

Agora eu adiciono um índice GIN em data:

CREATE INDEX ON jsonb_test USING gin (data);

Ao executar as consultas agora, a versão 2 faz o mesmo que acima, enquanto a versão 1 tem um novo plano:

 Bitmap Heap Scan on jsonb_test  (cost=28.77..372.05 rows=100 width=36) (actual time=0.081..0.083 rows=1 loops=1)
   Recheck Cond: (data @> '{"bla": 545}'::jsonb)
   Rows Removed by Index Recheck: 2
   Heap Blocks: exact=1
   Buffers: shared hit=10
   ->  Bitmap Index Scan on jsonb_test_data_idx  (cost=0.00..28.75 rows=100 width=0) (actual time=0.062..0.062 rows=3 loops=1)
         Index Cond: (data @> '{"bla": 545}'::jsonb)
         Buffers: shared hit=9
 Planning time: 0.084 ms
 Execution time: 0.122 ms

Isso já mostra que as duas versões não são totalmente equivalentes - um índice GIN na jsonbcoluna suporta apenas uma delas ( versão 1 ).

Pode-se definir um outro índice para ajudar a versão 2 :

CREATE INDEX ON jsonb_test ((data->>'bla'));

Agora a versão 2 dá o seguinte:

 Bitmap Heap Scan on jsonb_test  (cost=12.17..1323.49 rows=500 width=36) (actual time=0.065..0.070 rows=1 loops=1)
   Recheck Cond: ((data ->> 'bla'::text) = '545'::text)
   Heap Blocks: exact=1
   Buffers: shared hit=1 read=2
   ->  Bitmap Index Scan on jsonb_test_expr_idx  (cost=0.00..12.04 rows=500 width=0) (actual time=0.046..0.046 rows=1 loops=1)
         Index Cond: ((data ->> 'bla'::text) = '545'::text)
         Buffers: shared read=2
 Planning time: 0.480 ms
 Execution time: 0.133 ms

Neste experimento, não vejo uma grande diferença de desempenho entre os dois, dada a indexação adequada. No entanto, você deve considerar o seguinte :

A inserção em um índice GIN pode ser lenta devido à probabilidade de muitas chaves serem inseridas para cada item. Portanto, para inserções em massa em uma tabela, é aconselhável descartar o índice GIN e recriá-lo após terminar a inserção em massa.

Normalmente, diz-se que os índices BTree são mais baratos de manter (o que significa que as alterações de dados na tabela têm uma sobrecarga menor) que os índices GIN. Pela leitura, nem sempre é esse o caso - você deve testar essas soluções em seu próprio conjunto de dados. Por exemplo, não consigo dizer de cabeça se um conjunto de jsonbvalores muito complexos prefere isso ou aquilo.

Notas:

• para entender as semelhanças e diferenças dos json(b)operadores, a documentação oficial é uma excelente fonte.
• pode fazer sentido ler a apresentação de Bruce Momjian sobre técnicas de indexação .