# How to check the per-row on disk space usage in YugabyteDB?

**URL:** <https://forum.yugabyte.com/t/how-to-check-the-per-row-on-disk-space-usage-in-yugabytedb/741>\
**Category:** General\
**Created:** [June 25, 2020, 12:38pm UTC](https://forum.yugabyte.com/t/how-to-check-the-per-row-on-disk-space-usage-in-yugabytedb/741 "2020-06-25T12:38:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Edward\_Ribbery](https://avatars.discourse-cdn.com/v4/letter/e/a88e57/32.png) [@Edward\_Ribbery](https://forum.yugabyte.com/u/Edward_Ribbery)\
**Post date:** [June 25, 2020, 12:38pm UTC](https://forum.yugabyte.com/t/how-to-check-the-per-row-on-disk-space-usage-in-yugabytedb/741/1 "2020-06-25T12:38:41Z")

</div>

For a simple table with 4 bigint columns, 2 of which form the primary key:

```
 CREATE TABLE test(
           a bigint,
           b bigint,
           c bigint,
           d bigint,
      PRIMARY KEY((a), b)

```

Tried to measure the on-disk space usage using a replication factor 1  
setup (created using yb-ctl). This was tried using 2.1.6 version on Linux.

```
./bin/yb-ctl destroy
./bin/yb-ctl start

```

Then loaded the above table with 1 million rows (1000 distinct values for column “a”, each with 1000 distinct values for “b” and random values for c and d).

Then looked at space utilized:

```
% du -sh ./yb-data/tserver
410M ./yb-data/tserver

```

This seems to suggest that each row takes about 410 bytes. Note that the system does not have any other tables.

This seems on the high side. Is this a correct way of measuring the space utilized?

---

<div class="post-metadata">

**Author:** ![kannan](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kannan/32/18_2.png) [@kannan](https://forum.yugabyte.com/u/kannan)\
**Post date:** [June 25, 2020, 3:18pm UTC](https://forum.yugabyte.com/t/how-to-check-the-per-row-on-disk-space-usage-in-yugabytedb/741/2 "2020-06-25T15:18:31Z")

</div>

The -fs\_data\_dirs directory(ies) contains both the transaction logs (WAL) and SSTable files.

Quite likely much of the data is still in WAL and memtables and not yet flushed to SSTable format on disk. And the WAL files are not in compressed format. To get a better indication, we can either load a lot more data (such that the WAL portion is insignificant) or force a manual flush of the table, and then inspect the size of just the data directories.

Tried a similar table with 1,000,000 (1M) rows.

After inserting the rows data, but before forcing a flush:

```auto
$ du -hs yb-data/tserver/data |
60K yb-data/tserver/data

```

This confirms that most of the data is still in WAL and memtables.

After forcing a flush, using:

`./bin/yb-admin --master_addresses 127.0.0.1 flush_table <keyspace> <table>`

the data directory size is as follows:

```auto
$ du -hs yb-data/tserver/data
48M yb-data/tserver/data

```

So approximate on disk size per row for the given schema is about 48 bytes. This includes the overheads for the metadata (indexes, bloom filters, internal timestamps, etc.).