Subject: Tablespace size in TB

From: masheed ullah <[email-masked]>
Date: Sun, 3 May 2026 12:35:51 +0300

Hi,

Postgres = Version 13

OS=Linux 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.

-- 
Best Regards,
*Masheed Ullah*

---

From: Thiemo Kellner <[email-masked]>
Date: Sun, 3 May 2026 12:23:41 +0200

Hi

Is there a reason, you employ a version of PostgreSQL and OS too, that is no longer supported? Did you check, that v13 supports that kind of table spaces already? Maybe this support has been added only in a more recent version.

Kind regards

Thiemo

---

From: Thiemo Kellner <[email-masked]>
Date: Sun, 3 May 2026 12:28:41 +0200

Maybe you are looking for https://www.postgresql.org/docs/13/manage-ag-tablespaces.html

---

From: masheed ullah <[email-masked]>
Date: Sun, 3 May 2026 13:45:25 +0300

Thank you Thiemo, yes  the version 13 is outdated. Team is planning for an
upgrade.
I don't find any recommendations for splitting the single tablespace to
multiple.
So I need best practices / recommendations for Postgres.

On Sun, May 3, 2026 at 1:28 PM Thiemo Kellner <[email-masked]>
wrote:

> Maybe you are looking for
> https://www.postgresql.org/docs/13/manage-ag-tablespaces.html
>

Best Regards,
*Khattak*

---

From: Jan Karremans <[email-masked]>
Date: Sun, 3 May 2026 14:10:41 +0200

Hi Masheed,

Contrary to Oracle, a table space in PostgreSQL is a directory. And not a logical abstraction.

Moving tables from one table space to another becomes so much easier by that.

Does that help?

Cheers,

Jan

Verstuurd vanaf mijn iPhone

Op 3 mei 2026 om 12:45 heeft masheed ullah <[email-masked]> het volgende geschreven:

Thank you Thiemo, yes  the version 13 is outdated. Team is planning for an upgrade.
I don't find any recommendations for splitting the single tablespace to multiple.

On Sun, May 3, 2026 at 1:28 PM Thiemo Kellner <[email-masked]> wrote:

Best Regards,
Khattak

---

From: Laurenz Albe <[email-masked]>
Date: Sun, 03 May 2026 14:18:01 +0200

On Sun, 2026-05-03 at 12:35 +0300, masheed ullah wrote:
> 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.

Normally, using tablespaces won't speed up processing or backup; it just makes
administration slightly more complicated.
You shouldn't have created a tablespace in the first place (the default tablespace
is good), and I don't think you'll benefit from having more tablespaces.

To be more precise, a correct answer would depend on your backup method.
If you are using storage techniques to copy the 13TB, and those storage
techniques become faster if you have more than a single file system,
then you could benefit from more tabespaces.  Otherwise you won't.

What makes sense to split up is large tables.  Using partitioning might
make the individual partitions easier to maintain.

Yours,
Laurenz Albe

---

From: Ron Johnson <[email-masked]>
Date: Sun, 3 May 2026 10:43:43 -0400

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

To reinforce Jan's comment: a PG tablespace is *just a directory*.  Nothing
more, nothing less.

If your 13TB database is on one single spindle (or even SSD/NVMe), then
yes, adding more spindles or SSDs would be useful.  But if it's already on
multiple spindles, then LVM solves the problem for you.

As for long backup times, that's a function of hardware. How many threads
are you using? How parallel is the backup disk (or SAN)?  How's the network
configured?  Etc etc.

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!