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 1wJWiv-000WXH-1E for pgsql-general@arkaria.postgresql.org; Sun, 03 May 2026 13:19:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wJWis-003TVE-1Y for pgsql-general@arkaria.postgresql.org; Sun, 03 May 2026 13:19:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wJWir-003TV6-39 for pgsql-general@lists.postgresql.org; Sun, 03 May 2026 13:19:02 +0000 Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wJWip-00000000CeN-3J5H for pgsql-general@lists.postgresql.org; Sun, 03 May 2026 13:19:01 +0000 Received: by mail-oi1-x22b.google.com with SMTP id 5614622812f47-479aa2dbea2so1150617b6e.0 for ; Sun, 03 May 2026 06:18:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777814338; cv=none; d=google.com; s=arc-20240605; b=Uk/x9lwPEL8+fAtDwz+YNgro6rsdExSvrwNpkHatpWCbJiBsZv+mOla3D1HNpxulgi wHX/RJrWIjfccUwqLZSTtwdg1iLoWuMoY8odPi9LevyoCRA1Rd1z8wWtYSyTVZFaTSF7 Qpv1ox/o5I5NTkhIWcxgHaF49/mVxzGfwT8Xro5+D0rvU9FlTh/zoEZX3/hMkFA8LgzA YpDW1A2+upwUuEGljlR00GIskMHuNQDP9UYjkaV/Lalb7cR+9jx3rFySw0fiX8NfMAM4 i62s+wqEDpgd8VJSyxPQXVNCnLrx9Xv7ruFEyoo4OWpIsMcSbzCmoYr0oxJfqdPgV8fV svMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=fObisnHNbJeM2LjNFCnKTc+KvOgBQHjIJKwawOT4fus=; fh=ZQ1yrtRl6dx4eMYW5BBQB71vqCjL4ifqFoHfYw7CD90=; b=OShsyMguA6uxiWxUHI5apPR52geyD5Ihscg7ShZLmY9XGKGaQ/6QFtAsDZ1U9NVWaO xaiEfkNFDhuNlbaTlTN8s6H7AptYKBLA+UqR+josf+Y/DW8/HLkOs5t0zVUEkgjBRbSo rZDWwQo4AWfQvarDRoLYPiYR1UUFeg0UGjvbp6myDlCL3f/CuguREMIa7fxt85mR1V3E cT24RFw6w4FWBExF/M57Rva+t+RRMzvoUWeo4rjB9ZMp6kKNhTU3CWzbn72EoKEsgrzN 4tjVhdnBrNqKFYyEOHwNKQ9K1sqIrdwaAPCBxjOYS974BotLI+jtDbD5jVlBbHemSWEu icHw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gautherot.net; s=google; t=1777814338; x=1778419138; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fObisnHNbJeM2LjNFCnKTc+KvOgBQHjIJKwawOT4fus=; b=Uhxzb3hfP0flUF0Ec/yUm1Cfd+NIOqAKUe81OxfMmn5bZdb/1eZ4rGmOroVQ6zCZQW OB75usNBQmmZ4INtkP0IpqjZjkgY3yhJi0Q1bJRjaNtygkFKGjgC+NCllsCwK+4Kk9lh jPKcgMrQf/O6ZkZ8PXJOsbrVophQJsEbvdKa+ABf/tMESrlNtYcTeEygkNf1agqSf2I3 qidGlba8hBvxBErayMSNOudURjdSKEGMa5+7rOxDpOniVBp8vzjRhKwgGF4MHS8JGZOo VHJoXksn2UjXO2vUivRMVWlAFpzp0/laL0xYpiGcoJw51eM/zBS5U6Pf5XAHZVA3ChsM Hv5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777814338; x=1778419138; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fObisnHNbJeM2LjNFCnKTc+KvOgBQHjIJKwawOT4fus=; b=WBd1xeTamM3vVCS2I+OqBSJYhYbl7fKLa9Pp/zKNCJtFSn99PFob8kCRvCpws2hSFg pTz2Tad6sOzynIaULTqNJrweX+QEJwbVXCdXBbYdPND/zPHK+TnuCpOpzd9XCzSUNiO7 KIKjpFDJu9VMydDxoKNJ4lA5vmGJ6GDzTrJG1SAuXfAJ3MJwfqUpsEkN9/3Fiwn5J+Gv qaB4GKmDWKSBX29pYRWFU37WI9TACfzgqaM0sndxpnikaMsx5LW5k/0esoRPVxJaUz8s zM4Gsx50kQmwe7JQvSGhHZfA169r+96mSC6ydKtJxByBYkU7kk2c0zNXqQ37N+/iK+hF ElMg== X-Gm-Message-State: AOJu0Yz6gemaez9avkAAeXUp1s/IzCL5BA/qcKk2EC5HvGeu3zc1y2Ws c7ozQDSSTsyP3RKKKFwzadOCOR8aiIlGlA67ago1GGp7pdfe4IQ8K/t3oJ7Kqm5ix2/lwAMzXGY 6Zd2unqAO0tvHPMZOa1eEcZ5BsxQ+Kuj/Z8RmW9ke X-Gm-Gg: AeBDietJqG7opirqOJBK6Ir8dAl+mT9p/8/RaOypEJrTPGYCKHDtmtPe+zIQ7+atEyf 7lghJqGYSEABmbm8trK76xBXZoFUJLSWJkm5ozwrPk1b60brEPDq3VJa0MQFh07ESf2XgxEn59B wFOkfDTiD9HggvNfaM0clwSBYt54oKlXFADmZpI/NtAQ8ZHhleUVMDxnbcij+XG61OE0uAP8mYK EgdOq36gSXY/viz6EHC3uU1AZSt1mQccOXYjtrcIfuDQ3Xd8K/D1S+La0Q4tgvPECuT0EiZ90sf 5lVhtZCNjgHnFHZYi/p4C1UNwOTxvMchDeBcyZx5 X-Received: by 2002:a05:6808:4fcf:b0:47c:34fd:d391 with SMTP id 5614622812f47-47c8931483dmr2903194b6e.46.1777814338437; Sun, 03 May 2026 06:18:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olivier Gautherot Date: Sun, 3 May 2026 15:18:47 +0200 X-Gm-Features: AVHnY4KmWaNzh-lpaLUVOFL_jOpbcSjmrL5tw7K2fU8vlf3QsxsutTk-Tw-pQHU Message-ID: Subject: Re: Tablespace size in TB To: masheed ullah Cc: PostgreSQL General Content-Type: multipart/alternative; boundary="0000000000001e948e0650e9a8bc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001e948e0650e9a8bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Masheed, El dom, 3 de may de 2026, 11:36=E2=80=AFa.m., masheed ullah escribi=C3=B3: > Hi, > > Postgres =3D Version 13 > > OS=3DLinux Redhat version 8 > > Our team is using a single tablespace for the whole database. Its size is > more than 13TB. I am from an Oracle background and want to suggest that > they split the data in multiple tablespaces. It will not only improve the > performance & reduce the backup time. > > But I did not find any Postgres best practice or blog, to show as a > reference. > By any chance, do you mean partitions instead of tablespaces? Partitions are indeed recommended when your tables reach prohibitive sizes. With the relevant partition key and indexes, it can significantly improve the performance and, with a smart backup strategy, reduce the backup size and time. Hope it helps -- Olivier Gautherot > -- > Best Regards, > *Masheed Ullah* > > > --0000000000001e948e0650e9a8bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Masheed,

El dom, 3 de may de 2026, 11:36=E2=80=AFa.m., masheed ullah <= ;masheedullah@gmail.com> e= scribi=C3=B3:
Hi,

Post= gres =3D Version 13

OS=3DLinux = Redhat version 8

Our team is us= ing a single tablespace for the whole database. Its size is more than 13TB.= I am from an Oracle background and want to suggest that they split the dat= a in multiple tablespaces. It will not only improve the performance & r= educe the backup time.

But I did not find= any Postgres best practice or blog, to show as a reference.


By = any chance, do you mean partitions instead of tablespaces? Partitions are i= ndeed recommended when your tables reach prohibitive sizes. With the releva= nt partition key and indexes, it can significantly improve the performance = and, with a smart backup strategy, reduce the backup size and time.

Hope it helps<= br>--
Olivier Gautherot


--
Best Regards, <= font face=3D"sans-serif" size=3D"2">
Masheed Ullah


--0000000000001e948e0650e9a8bc--