TIL Postgres: Logical vs. Physical Backups
Tags: todayilearned, postgres, supabase
Published: 2020-07-17 09:12:30

As anyone who has been put in charge of a database knows, setting up backups and recovering from them are perhaps essential components of one's skillset. You probably would have already tried one or more of the many tools and ways in Postgres to achieve them, some of which we will cover in future posts. All can be categorized into two types of backups: *logical* and *physical*. In this week's edition of **TIL Postgres**, we will take a quick look at each one and discuss the situations in which they are best used for.

## Logical Backups
This form of backup is typically achieved by [translating all the data into a set of SQL commands and writing it into a single file](https://www.postgresql.org/docs/current/backup-dump.html). This can then be fed to any database cluster to recreate everything. In your CLI, performing logical backups can be as easy as:

```shell
pg_dump db_name > file_name.sql
```

for a single database, and:

```shell
pg_dumpall > file_name.sql
```

for an entire database cluster. Both the [pg_dump](https://www.postgresql.org/docs/current/app-pgdump.html) and [pg_dumpall](https://www.postgresql.org/docs/current/app-pg-dumpall.html) utilities have their respective additional options for you to choose from and set up your desired logical backup setting. Recovering from them is comparably as simple:

```shell
psql -d db_name -f file_name.sql
```

### What is it good for?
#### Simpler and quicker way of performing backups
As shown above, a single command is enough to perform a logical backup, and another to recover from it. As a novice with databases, this would be an ideal and non-intimidating start in making sure that your database is backed up at all times.

#### Migration between different major versions of Postgres
If you are planning to migrate to a different major version of Postgres (for eg. from Postgres 11 to Postgres 12), logical backups via `pg_dumpall` would surely be your [tool of choice](https://www.postgresql.org/docs/current/upgrading.html). This is mainly because internal data storage formats may differ between major versions. This is the basis of physical backups, hence eliminating it as an option. We'll go deeper into migrations and how to perform them in another post.

#### Backing up a single specific database
With `pg_dump`, you can constantly just back up the database of your choice without having to think about the rest.

## Physical Backups
Physical backups pertain more to the actual set of files or file systems where all your data are stored. Performing a backup can just involve [taking a snapshot](https://www.postgresql.org/docs/current/backup-file.html) of all the files involved by making a copy of them and storing it somewhere safe.

### What is it good for?
#### More ideal for larger databases
As your database grows to the size of a few gigabytes, backing it up through physical backups is more ideal than through logical backups. As explained [here](https://devcenter.heroku.com/articles/heroku-postgres-data-safety-and-continuous-protection#the-performance-impact-of-logical-backups), over time, performing logical backups in large databases could lead to degraded performance for other queries. Given the long run time as well to successfully perform a logical backup on a large database, errors have a higher chance of occurring, making the eventual backup unusable.

#### Achieving Point in Time Recovery
Another form of physical backup called [Write Ahead Log](https://www.postgresql.org/docs/current/wal-intro.html) (WAL) files can be used together with a backed-up file system to [recover a database up to any chosen point in time](https://www.postgresql.org/docs/current/continuous-archiving.html). When disaster strikes, this would be one of the best options in recreating a database up to the point right before the unfortunate happens. This greatly minimizes [Recovery Point Objective (RPO)](https://www.ibm.com/services/business-continuity/rpo) along the way. Even better, a lot of tools such as [WAL-G](https://github.com/wal-g/wal-g) are readily available to simplify the steps involved in setting everything up.


## Conclusion
All in all, logical and physical backups are generated differently from one another. Neither has an advantage over the other. Depending on your needs, each brings unique uses to the table:

| Logical | Physical |
|:--------|:---------|
| Simpler way of getting started with backups. | Better way of handling backups for larger database clusters. |
| Using it to migrate between different major versions of Postgres. | Using it for Point in Time Recovery. |
| Having the option to back up a single database. |   |

---
**TIL Postgres** is an ongoing series by [Supabase](https://supabase.io) that aims to regularly share snippets of information about PostgreSQL and hopefully provide you with something new to learn. :wink:

Any new posts or announcements of our future features and freebies will be made here on DEV first. Follow us so that you don't miss out.

![follow gif](https://res.cloudinary.com/practicaldev/image/fetch/s--uyA__P-6--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/jf7adc5e3kbdu4luxvt4.gif)