Tablespace size in TB

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

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

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 <thiemo@gelassene-pferde.biz>
wrote:

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

Best Regards,
*Khattak*

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

On Sun, 2026-05-03 at 14:10 +0200, Jan Karremans wrote:

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.

I am confused. Yes, if you have more than a single (default) tablespace,
moving tables between tablespaces becomes possible and hence easier.
But why would you want to move tables between tablespaces in the first place?

Yours,
Laurenz Albe

My thinking would be to have the different directories on different tiers of storage.

Cheers,
Jan

Just to check like Oracle, parallelism works well with multiple tablespaces.
Moving tables/ indexes to multiple tablespaces to use the parallelism to
boost the backup speed. With a single tablespace, parallelism will not work.

On Sun, May 3, 2026 at 3:21 PM Laurenz Albe <laurenz.albe@cybertec.at>
wrote:

The issue is, 13tb database BARMAN backup is taking 20 hours and restore
takes 24 hours.
So the main agenda is to reduce the backup time to less than 10hours.

So does any solution/ tool I recommend to client.

. I just checked pgBeckRest has no more support, so I can not suggest it to
client.

On Sun, May 3, 2026 at 3:25 PM Jan Karremans <karremans.ja@gmail.com> wrote:

My thinking would be to have the different directories on different tiers
of storage.

Cheers,
Jan

On 3 May 2026, at 14:21, Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Sun, 2026-05-03 at 14:10 +0200, Jan Karremans wrote:

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.

I am confused. Yes, if you have more than a single (default) tablespace,
moving tables between tablespaces becomes possible and hence easier.
But why would you want to move tables between tablespaces in the first

place?

Yours,
Laurenz Albe

--
Best Regards,
*Masheed Ullah*

You can safely recommend pgBackRest as several PostgreSQL companies have already stepped up to take over/fork pgBackRest.

Hi Masheed,

El dom, 3 de may de 2026, 11:36 a.m., masheed ullah <masheedullah@gmail.com>
escribió:

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.

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

On Sun, May 3, 2026 at 5:36 AM masheed ullah <masheedullah@gmail.com> wrote:

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.

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!

On Sun, 2026-05-03 at 14:25 +0200, Jan Karremans wrote:

On 3 May 2026, at 14:21, Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Sun, 2026-05-03 at 14:10 +0200, Jan Karremans wrote:

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.

I am confused. Yes, if you have more than a single (default) tablespace,
moving tables between tablespaces becomes possible and hence easier.
But why would you want to move tables between tablespaces in the first place?

My thinking would be to have the different directories on different tiers of storage.

I see. That can indeed improve the throughput, but you don't need tablespaces for
that: it would be simpler to define a striped logical volume.

Yours,
Laurenz Albe

On Sun, 2026-05-03 at 15:26 +0300, masheed ullah wrote:

Just to check like Oracle, parallelism works well with multiple tablespaces.
Moving tables/ indexes to multiple tablespaces to use the parallelism to boost
the backup speed. With a single tablespace, parallelism will not work.

That may be the case with Oracle, but not with PostgreSQL.

pg_basebackup will not parallelize at all.

I found the following article about backup tools useful:
https://thebuild.com/blog/2026/04/30/after-pgbackrest/

You should consider alternatives to parallelism, since parallelism
will only help up to the limit where the disk is saturated.
One think you should seriously consider is incremental backup,
which would reduce the backup time considerably (but not the
restore time).

Yours,
Laurenz Albe

On May 3, 2026, at 08:54, Greg Hennessy <greg.hennessy@gmail.com> wrote:

Is the fact that other companies are taking
Over support for pgBackRest documented?

Just speaking for my company:

https://github.com/pgexperts/pgxbackup

Even with Oracle you need to know the architecture of your storage to decide whether you can expect performance improvements. If you happen to have some kind of NAS, you partitions for the different table spaces might reside on the very same hardware and you probably gain naught.

03.05.2026 14:27:01 masheed ullah <masheedullah@gmail.com>:

Hi Greg,

On Sun, May 3, 2026 at 5:55 PM Greg Hennessy <greg.hennessy@gmail.com>
wrote:

Is the fact that other companies are taking
Over support for pgBackRest documented?

Making a company-branded fork is the easiest (and wrong) step. Planning how
to pick up the pgBackRest project or create a sustainable, community-driven
fork that re-establishes at least the same reputation requires longer
preparation. We all need patience.

--
Ilya Kosmodemiansky
CEO, Founder

Data Egret GmbH
Your remote PostgreSQL DBA team
T.: +49 6821 919 3297
ik@dataegret.com

On May 3, 2026, at 22:55, Ilya Kosmodemiansky <ik@dataegret.com> wrote:
Making a company-branded fork is the easiest (and wrong) step. Planning how to pick up the pgBackRest project or create a sustainable, community-driven fork that re-establishes at least the same reputation requires longer preparation. We all need patience.

Dave was quite clear that someone "picking up the pgBackRest project" was not on the table. I don't think that avenue is open.

I would feel more sanguine about the idea that a new community-suported fork will emerge if there were an existence proof of it happening in the PostgreSQL community. I can't think of one.

We need to tell our customers something, and "the community will ride in and maintain pgBackRest, just you wait" isn't a satisfactory answer. We can tell clients all we want that the current pgBackRest version works just fine, they don't have to change, a community standard version will emerge, and so forth, but that falls on deaf ears. This is a backup tool; it's second only to PostgreSQL itself in the "must work all the time" camp. All they hear is what it says on the repo, which is "pgBackRest is no longer being maintained."

I think it more likely that an entirely new backup tool will emerge, become the de facto community standards, and then we will move off pgBackRest (and its forks) onto that.