# Source: https://docs.hypermode.com/dgraph/concepts/posting-list.md

# Posting List and Tablet

<Info>
  We're overhauling Dgraph's docs to make them clearer and more approachable. If
  you notice any issues during this transition or have suggestions, please
  [let us know](https://github.com/hypermodeinc/docs/issues).
</Info>

Posting lists and tablets are internal storage mechanisms and are generally
hidden from users or developers, but logs, core product code, blog posts and
discussions about Dgraph may use the terms "posting list" and "tablet."

Posting lists are a form of inverted index. Posting lists correspond closely to
the RDF concept of a graph, where the entire graph is a collection of triples,
`<subject> <predicate> <object>`. In this view, a posting list is a list of all
triples that share a `<subject>+<predicate>` pair.

(Note that in Dgraph docs, we typically use the term "relationship" rather than
predicate, but here we will refer to predicates explicitly.)

The posting lists are grouped by predicate into `tablets`. A tablet therefore
has all data for a predicate, for all subject UIDs.

Tablets are the basis for data shards in Dgraph. In the near future, Dgraph may
split a single tablet into two shards, but currently every data shard is a
single predicate. Every server then hosts and stores a set of tablets. Dgraph
will move or allocate different tablets to different servers to achieve balance
across a sharded cluster.

### Example

If we're storing friendship relationships among four people, we may have four
posting lists represented by the four tables below:

| Node    | Attribute | Value   |
| ------- | --------- | ------- |
| person1 | friend    | person2 |
| person1 | friend    | person4 |

 

| Node    | Attribute | Value   |
| ------- | --------- | ------- |
| person2 | friend    | person1 |

 

| Node    | Attribute | Value   |
| ------- | --------- | ------- |
| person3 | friend    | person2 |
| person3 | friend    | person4 |

 

| Node    | Attribute | Value   |
| ------- | --------- | ------- |
| person4 | friend    | person2 |
| person4 | friend    | person1 |
| person4 | friend    | person3 |

 

The corrsponding posting lists would be something like:

```
person1UID+friend->[person2UID, person4UID]
person2UID+friend->[person1UID]
person3UID+friend->[person2UID, person4UID]
person4UID+friend->[person1UID, person2UID, person3UID]
```

 

Similarly, a posting list will also hold all literal value properties for every
node. E.g. consider the names of people in these three tables:

| Node    | Attribute | Value   |
| ------- | --------- | ------- |
| person1 | name      | "James" |
| person1 | name      | "Jimmy" |
| person1 | name      | "Jim"   |

 

| Node    | Attribute | Value   |
| ------- | --------- | ------- |
| person2 | name      | "Rajiv" |

 

| Node    | Attribute | Value    |
| ------- | --------- | -------- |
| person3 | name      | "Rachel" |

  The posting lists would look like:

```
person1UID+name->["James", "Jimmy", "Jim"]
person2UID+friend->["Rajiv"]
person3UID+friend->["Rachel"]
```

 

Note that person4 has no name attribute specified, so that posting list would
not exist.

In these examples, two predicates (relations) are defined, and therefore two
tablets will exist.

The tablet for the `friend` predicate will hold all posting lists for all
"friend" relationships in the entire graph. The tablet for the `name` property
will hold all posting lists for `name` in the graph.

If other types such as Pets or Cities also have a name property, their data will
be in the same tablet as the Person names.

### Performance implications

A key advantage of grouping data into predicate-based shards is that we have all
the data to do one join in one `tablet` on one server/shard. This means, one RPC
to the machine serving that `tablet` will be adequate, as documented in
[How Dgraph Minmizes Network Calls](./minimizing-network-calls).

Posting lists are the unit of data access and caching in Dgraph. The underlying
key-value store stores and retrieves posting lists as a unit. Queries that
access larger posting lists will use more cache and may incur more disk access
for un-cached posting lists.