How much space do null values take up in PostgreSQL?

Many people chose to use a _non-relational_ ("NoSQL") database (_such as MongoDB or Cassandra_) from the _start_ of their project/app because they want the "flexibility" of not having a "rigid" schema. From _experience_ we have _observed_ that the _vast majority_ of Apps can actually _hugely benefit_ from developers thinking about schema up-front rather than "dumping data into mongo" and dealing with out to query and relate it _later_.

One of the common questions when using PostgreSQL is around having "empty" fields in a table.
Imagine that you have a schema for a **`person`** (_a human being that uses your SaaS product_).
That person might have a _wide_ range of data associated with them. see: https://github.com/dwyl/fields/issues/4
Let's consider a typical record:

+ name: Alex
+ dob (Date of Birth): 1970-01-01
+ email: alex@gmail.com
+ facebook: `null`
+ mobile: +44789654321
+ instagram: `null`
+ twitter: `alex`
+ website: hialex.com

As you can see from this basic "person" record, Alex does not have an [instagram](https://youtu.be/NGeU17Df8cw) or [facebook](https://www.ted.com/talks/cal_newport_why_you_should_quit_social_media) account.
Both columns in the table will be **`null`**:

| `inserted_at ` | **`name`** | `email (PK)` | `facebook` | `mobile` | `instagram` | `twitter` | `website` |
| ------ | ------ | ------ | ------- | ------ | ------ | ------ | ------ |
| 1541609554 | Alex | alex@gmail.com | null | +44789654321 | null | alex | hialex.com |
| 1541609876 | Jo | jo@dwyl.com | null | +1212456789 | jopix | joblogs | iamjo.net |

---

## Question: Does having `null` values take up a lot of Disk Space?

## Answer: No, Each `null` value only uses _one_ `bit` on disk.

For argument's sake, let's represent the data this way "on disk":
```
1541609554|Alex|alex@gmail.com||+44789654321||alex|hialex.com|
```
So in the above example, the Alex's _row_ of data in the **`people`** table is **62 bytes** or **496 bits**:


In the scheme of things, having a few `null` columns will not have a major impact on the disk usage.
If your database table has 30 such `default null` fields, it would still only be 30 bits per row.
In general, we will only add a fields to a table/schema that has a high likelihood of containing data.
We aren't going to have a field for **`myspace`** ...

Obviously it would be _even_ better if `null` data took up _zero_ bits, but sadly that is not realistic.
Because the underlying data storage needs a way of "representing" the `null` value.

## Conclusion: having structured relational data queries is "_worth it_" for a few bits of `null` data.

I feel that the "trade off" of having _structured relational_ data (_when appropriate_)
is worthwhile for the _sane_ querying and having a few bits of `null` data in the rows, is a "fair price".
> We should _re-visit_ this hypothesis in a few months if we notice any "slow queries".

## Relevant Stack Overflow / Databases Q/A

+ https://stackoverflow.com/questions/4229805/how-much-disk-space-is-needed-to-store-a-null-value-using-postgresql-db
+ https://dba.stackexchange.com/questions/91848/how-do-completely-empty-columns-in-a-large-table-affect-performance

---

> Note: some of NoSQL databases have _good_ use-cases for specific types of Apps, data & querying.
e.g: Neo4J https://github.com/dwyl/learn-neo4j for Graph data
or Elasticsearch for Full-text Search: https://github.com/dwyl/learn-elasticsearch
That is not in question here and is a topic for another issue/discussion.
_Most_ people who are starting out with building apps should learn how to store data in a _structured_ way to ensure they _understand_ how to query/analyse it and avoid confusion about related data.