# PostgreSQL 9.4 - Looking up (with JSONB and logical decoding)

DevFeed: [PostgreSQL 9.4 - Looking up (with JSONB and logical decoding)](<https://devfeed.tech/articles/postgresql-9-4-looking-up-with-jsonb-and-logical-decoding-41164.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2014/03/24/PostgreSQL-9.4-Looking-up-with-JSONB-and-logical-decoding/>)

Author: Map

Published: 2014-03-24T20:55:56Z

Content type: article

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [JSON](<https://devfeed.tech/topics/json.md>), [Decoding](<https://devfeed.tech/topics/decoding.md>), [Database](<https://devfeed.tech/topics/database.md>), [Replication](<https://devfeed.tech/topics/replication.md>)

Tags: [decoding](<https://devfeed.tech/tags/decoding.md>), [indexing](<https://devfeed.tech/tags/indexing.md>), [jsonb](<https://devfeed.tech/tags/jsonb.md>), [logical](<https://devfeed.tech/tags/logical.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>)

## AI overview

This article examines PostgreSQL 9.4 features, focusing on JSONB and logical decoding. It explains how JSONB provides binary JSON document storage and how GIN indexes can automatically index document keys and values. The supplied text begins discussing logical decoding but is incomplete.

## Source excerpt

Just a few weeks back I wrote a article discussing many of the things that were likely to miss making the 9.4 PostgreSQL release. Since that post a few weeks ago the landscape has already changed, and much more for the positive. The lesson here, is never count Postgres out. As Bruce discussed in a recent interview, Postgres is slow and steady, but much like the turtle can win the race. So onto the actual features: JSONB JSON has existed for a while in Postgres. Though the JSON that exists today simply validates that your text is valid JSON, then goes on to store it in a text field. This is fine, but not overly performant. If you do need some flexibility of your schema and performance without much effort then hstore may already work for you today, you can of course read more on this in an old post comparing hstore to json. But let's assume you do want JSON and a full document store, which is perfectly reasonable. Your option today is still best with the JSON datatype. And if you're retrieving full documents this is fine, however if you're searching/filtering on values within those documents then you need to take advantage of some functional indexing. You can do this some of the built-in operators or with full JS in Postgres. This is a little more work, but also very possible to get good performance. Finally, onto the perfect world, where JSON isn't just text in your database. For some time there's been a discussion around hstore and its future progress and of course the future of JSON in Postgres. These two worlds have finally heavily converged for PostgreSQL 9.4 giving you the best of both worlds. With what was known as hstore2, by The Russians under the covers, and collective efforts on JSONB (Binary representation of JSON) which included all the JSON interfaces you'd expect. We now have full document storage and awesome performance with little effort. Digging in a little further, why does it matter that its a binary representation? Well under the covers building o