если смотреть отдельно размеры таблиц, там не получается 1025MB

м.б. VACUUM давно не было?

Или индексы большие (pg_dump не дампит индексы, только их определения), в то время как pg_database_size выдаёт размер с учётом индексов.

хм, индексов там достаточно, да

А, так это dump, а не backup — размеры могут сильно отличаться в любую сторону, это нормально.

🤔
а чем дамп отличается от бэкапа..

ну вот и причина, скорее всего
Часто бывает наоборот — несжатый архив больше чем pg_database_size
Это связано с тем, что поля text, json, jsonb, bytea хранятся в бд  в сжатом виде, и при дампе без сжатия "раздуваются"

сейчас Читал про разницу между дампом и бэкапом.
"Разница в том, что в случае повреждения файлов или операционной системы из бэкапа можно все восстановить. А дамп используется для разбора причин возникновения сбоя."

получается, если дамп сделан через pg_dump, в случае повреждения базы через этот дамп ее не получится восстановить?

Ох.. как-то всё слишком безапелляционно сказано, не бывает так в реальном мире...
По моим представлениям бэкапы (или "дампы" — это, в общем смысле и отрыве от конкретной СУБД, всё игры слов) делятся на два типа: логический и физический.
pg_dump реализует логический бэкап (именно поэтому он, например, не бэкапит значения индексов), а физический — это просто копирование файлов бд (которое, без остановки бд и сброса всех логов транзакций может привести к неконсистентной копии —  в случае высоконагруженной БД точно приведет — но это другая тема)

Примерно всем. ;)
Дамп — просто последовательность SQL-команд для успешного (в обычном случае) воссоздания базы.
А backup — это "физическая" копия данного кластера БД.

Ну так все современные СУБД используют WAL (этот принцип, названия / детали реализаций отличаются), и, с учётом этого, возможно снимать консистентные backup-ы.

Позвольте не согласиться.
открываем https://www.postgresql.org/docs/9.1/backup.html
и видим, что под заголовком "Backup and Restore" скрывается и описание работы с pg_dump, и описания создания копии на уровне файловой системы, таким образом, в понятие "бэкап" входит и термин "дамп". Всё это игры слов кмк

А то, что вы описали — последовательность sql и "физическая" копия — это разные режимы работы pg_dump (за исключением того, что "бинарная" копия в терминологии постгре не является аналогом "физической" копии)

Че там постгре уже научилась делать бекап одной бд для разворачивания на новом кластере?

Без полной остановки БД (со сбросом логов транзакций) копированием файлов БД на уровне файловой системы консистентные бэкапы снимать нельзя. Они могут получится консистентными (и то придётся подрезать логи) только случайно, если база не нагружена записью.

Нет, не позволю. ;)

> и видим, что под заголовком "Backup and Restore" скрывается и описание работы с pg_dump

Эта документация написана не DBA (и чести проекту PostgreSQL не делает, IMNSHO), и я лично уже отсылал предложения о её исправлении, кстати.

> Всё это игры слов кмк

Вам "к" неправильно. ;)
Потому что backup — это такая штука, на основании которой можно построить recovery strategy, а на дампах в нетрирвиальном случае можно "построить" только её серьёзный провал.

> это разные режимы работы pg_dump

Нет. pg_dump вообще не снимает копий такого рода (физических/файловых), Вы путаете.

Да, я знаю. И написал то же самое, нет?

И всё же я буду верить официальной документации (по крайней мере до тех  пор, пока она не измениться), а не частному мнению. Простите.

Нет, не научился, конечно (и не научится, если принцип работы WAL не изменят кардинально).
И СУБД называется постргес. ;)

Т.е. Вам не важно, соответствует ли оно реальности или нет, простите?