Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPgo6-000xH4-1Q for pgsql-general@arkaria.postgresql.org; Wed, 20 May 2026 13:17:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPgo4-007mx7-1J for pgsql-general@arkaria.postgresql.org; Wed, 20 May 2026 13:17:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPgo4-007mwy-04 for pgsql-general@lists.postgresql.org; Wed, 20 May 2026 13:17:53 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wPgo2-00000000YRk-3vh3 for pgsql-general@lists.postgresql.org; Wed, 20 May 2026 13:17:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version :References:Reply-To:Message-ID:Subject:Cc:To:Sender:From:Date:Content-ID: Content-Description; bh=HG9pvEAeQmD75ybtbnVhvaLKa5TQ+uPf6Pv8aKzWV/8=; b=LKRPP a59Keq3aXhABZEITcBTMgnbsDLzcJsTHnA4SRfXtcWstbiHtF/swOyaTdQvsfjXe7zgHr342WKQ+V Y+LRuLafjXyY0FF0OmAQSCQyT9Wsl2uBqF6j0X0glhREj56O3o9UQMevWctsTA+Owf9NPmCXuSSNv 1wy5F2gPs7SQ=; Received: from depesz by depesz.com with local (Exim 4.96) (envelope-from ) id 1wPgo1-007zdU-1A; Wed, 20 May 2026 15:17:49 +0200 Date: Wed, 20 May 2026 15:17:49 +0200 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: Ertan =?utf-8?B?S8O8w6fDvGtvZ2x1?= Cc: pgsql-general@lists.postgresql.org Subject: Re: Large backup size of pg_dump Message-ID: Reply-To: depesz@depesz.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 20, 2026 at 10:17:57AM +0300, Ertan Küçükoglu wrote: > Hello, > > I am using PostgreSQL 18.4 x64 on Windows Server 2022. There is a very > small single database in the cluster. > > There are hourly pg_dump backups scheduled and database backup size is > around 10GB. 1. pg_dump is not the best choice for backups. 2. When using pg_dump, use at least -Fd, and -jX to make the dumps work in parallel 3. Check what is using the most space in dump, and compare it with db 4. What exactly do you mean by "BLOB"? What is the actual datatype of the field? 5. What is `\l+ your_db_name` output from psql? > I didn't understand about 2.5 times bigger backup sizes than the total > cluster size. I do not know what to check either. Is there a way for me to > make the hourly backup size smaller? Consider compressing it? Or use some backup tool that handles incremental/differential backups, like, for example, backrest. depesz