# Kv store policy

**URL:** <https://forum.yugabyte.com/t/kv-store-policy/4114>\
**Category:** General\
**Created:** [January 9, 2025, 9:54pm UTC](https://forum.yugabyte.com/t/kv-store-policy/4114 "2025-01-09T21:54:36Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![yugi](https://avatars.discourse-cdn.com/v4/letter/y/97f17d/32.png) [@yugi](https://forum.yugabyte.com/u/yugi)\
**Post date:** [January 9, 2025, 9:54pm UTC](https://forum.yugabyte.com/t/kv-store-policy/4114/1 "2025-01-09T21:54:36Z")

</div>

I would like to understand, how the yugabyte stores data on the low level. As I understand, the yugabyte is built on the DocDB and RocksDB. So at the end, it stores data as key value.In short the key is built based on the primary key columns ([doc](https://docs.yugabyte.com/preview/architecture/docdb/data-model/#primary-key-columns)).  
The value is stored as document with subkeys and corresponding values.

Do I get it right that yugabyte stores it as column per cell ? So each column is separate key,value.

When I have table:

```auto
CREATE TABLE sample
(
    id INT NOT NULL,
    name INT NOT NULL,
    doc jsonb NOT NULL,
    creation_date timestamp,
    PRIMARY KEY (id)
);

```

One record will result into following key values:

```auto
DocumentKey1, T10 -> {} // This is an init marker
DocumentKey1, name, T10 -> Value1
DocumentKey1, doc, T10 -> Value2
DocumentKey1, creation_date, T10 -> Value3

```

As I understand, it is not possible to define column families on my own. Correct?

Based on the links:

> **[DocDB data model](https://docs.yugabyte.com/preview/architecture/docdb/data-model/)**
>
> Understand how DocDB stores table rows as keys and values

> **[Yugabyte vs. CockroachDB: Unpacking competitive benchmark claims](https://www.cockroachlabs.com/blog/unpacking-competitive-benchmarks/#initial%23SQL-on-top-of-KV)**
>
> Yugabyte frequently compares themselves to CockroachDB. We investigated their claims. This is our analysis of CockroachDB vs. Yugabyte v2.0.0.

> <https://github.com/YugaByte/yugabyte-db/issues/147>
>
> I don't know how much more efficient the DocDB is compared to RocksDB, but cockr…oachdb ended up grouping all columns into 1 kv by default: https://www.cockroachlabs.com/docs/stable/column-families.html
> 
> This the same for cases when you mostly want to get back the whole array/map/set. 
> 
> Maybe even using the Merge operator https://github.com/facebook/rocksdb/wiki/Merge-Operator to add non-reading-updates like tokumx https://www.percona.com/doc/percona-tokumx/fast\_updates.html
> 
> Makes sense ?

---

<div class="post-metadata">

**Author:** ![FranckPachot](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/franckpachot/32/353_2.png) [@FranckPachot](https://forum.yugabyte.com/u/FranckPachot)\
**Post date:** [January 9, 2025, 11:19pm UTC](https://forum.yugabyte.com/t/kv-store-policy/4114/2 "2025-01-09T23:19:38Z")

</div>

Hi, yes, the idea that there is one key for each column value was true until we implemented packed rows. Now, when you insert, each SQL row corresponds to a single key-value pair in RocksDB. When you update a column, it creates an additional key-value pair because the version timestamp is included in the key, along with the new column value. After the compaction, these are repacked into a single key-value per row.

---

<div class="post-metadata">

**Author:** ![yugi](https://avatars.discourse-cdn.com/v4/letter/y/97f17d/32.png) [@yugi](https://forum.yugabyte.com/u/yugi)\
**Post date:** [January 10, 2025, 9:00am UTC](https://forum.yugabyte.com/t/kv-store-policy/4114/3 "2025-01-10T09:00:56Z")

</div>

Hi, thanks for the explanation, it is clear right now. And I’ve just ran into this page [Packed rows in DocDB | YugabyteDB Docs](https://docs.yugabyte.com/preview/architecture/docdb/packed-rows/) where it is clearly described.