Thread

Tablespace size in TB

masheed ullah <masheedullah@gmail.com> — 2026-05-03T09:35:51Z

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*

Tablespace size in TB

Thiemo Kellner <thiemo@gelassene-pferde.biz> — 2026-05-03T10:23:41Z

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

Tablespace size in TB

Thiemo Kellner <thiemo@gelassene-pferde.biz> — 2026-05-03T10:28:41Z
```
Maybe you are looking for https://www.postgresql.org/docs/13/manage-ag-tablespaces.html
```

Re: Tablespace size in TB

masheed ullah <masheedullah@gmail.com> — 2026-05-03T10:45:25Z

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*

Re: Tablespace size in TB

Jan Karremans <karremans.ja@gmail.com> — 2026-05-03T12:10:41Z

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 <masheedullah@gmail.com> 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.
          
          
            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

Re: Tablespace size in TB

Laurenz Albe <laurenz.albe@cybertec.at> — 2026-05-03T12:18:01Z

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

Re: Tablespace size in TB

Laurenz Albe <laurenz.albe@cybertec.at> — 2026-05-03T12:21:23Z

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

Re: Tablespace size in TB

Jan Karremans <karremans.ja@gmail.com> — 2026-05-03T12:25:26Z

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

Re: Tablespace size in TB

masheed ullah <masheedullah@gmail.com> — 2026-05-03T12:26:45Z

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:

> 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
>

Re: Tablespace size in TB

masheed ullah <masheedullah@gmail.com> — 2026-05-03T12:30:56Z

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*

Re: Tablespace size in TB

Jan Karremans <karremans.ja@gmail.com> — 2026-05-03T12:47:56Z

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

> On 3 May 2026, at 14:30, masheed ullah <masheedullah@gmail.com> 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 <mailto: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 <mailto: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 
> 
>

Re: Tablespace size in TB

Olivier Gautherot <ogautherot@gautherot.net> — 2026-05-03T13:18:47Z

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


> --
> Best Regards,
> *Masheed Ullah*
>
>
>

Re: Tablespace size in TB

Ron Johnson <ronljohnsonjr@gmail.com> — 2026-05-03T14:43:43Z

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!

Re: Tablespace size in TB

Greg Hennessy <greg.hennessy@gmail.com> — 2026-05-03T15:54:57Z

Is the fact that other companies are taking 

  Over support for pgBackRest documented?


  



  

  
    Sent from my iPhone
  
  
    

    
      On May 3, 2026, at 8:48 AM, Jan Karremans <karremans.ja@gmail.com> wrote:

      

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

      
        

        
          
            On 3 May 2026, at 14:30, masheed ullah <masheedullah@gmail.com> 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

Re: Tablespace size in TB

Laurenz Albe <laurenz.albe@cybertec.at> — 2026-05-03T16:59:41Z

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

Re: Tablespace size in TB

Laurenz Albe <laurenz.albe@cybertec.at> — 2026-05-03T17:04:29Z

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

Re: Tablespace size in TB

Christophe Pettus <xof@thebuild.com> — 2026-05-03T17:07:26Z


> 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

Re: Tablespace size in TB

Thiemo Kellner <thiemo@gelassene-pferde.biz> — 2026-05-03T19:38:59Z

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>:

> 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:
>> 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
> 
> 
>

Re: Tablespace size in TB

Ilya Kosmodemiansky <ik@dataegret.com> — 2026-05-04T05:55:34Z

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

pgBackRest maintenance (was Re: Tablespace size in TB)

Christophe Pettus <xof@thebuild.com> — 2026-05-04T06:45:53Z

> 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.

Re: Tablespace size in TB

Frank Lanitz <frank@frank.uvena.de> — 2026-05-12T05:40:44Z

On 5/3/26 2:47 PM, Jan Karremans wrote:
> You can safely recommend pgBackRest as several PostgreSQL companies have already stepped up to take over/fork pgBackRest.

And ensure the customer is supporting developing / maintaining affords.
What's free cannot be good, isn't it? ;)

.f

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Bruce Momjian <bruce@momjian.us> — 2026-05-14T17:26:45Z

On Sun, May 3, 2026 at 11:45:53PM -0700, Christophe Pettus wrote:
>
>
> > 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-sported fork will emerge if there were an existence proof
> of it happening in the PostgreSQL community.  I can't think of one.

That happened with pgbouncer where development stopped and a new team
picked it up.  I think Peter Eisentraut was involved.  With pgbackrest,
I think a similar thing would need to happen, but with a new name.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Josef Šimánek <josef.simanek@gmail.com> — 2026-05-14T17:54:30Z

čt 14. 5. 2026 v 19:26 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
>
> On Sun, May 3, 2026 at 11:45:53PM -0700, Christophe Pettus wrote:
> >
> >
> > > 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-sported fork will emerge if there were an existence proof
> > of it happening in the PostgreSQL community.  I can't think of one.
>
> That happened with pgbouncer where development stopped and a new team
> picked it up.  I think Peter Eisentraut was involved.  With pgbackrest,
> I think a similar thing would need to happen, but with a new name.

I think David is back and no fork is needed currently.
https://github.com/pgbackrest/pgbackrest/commit/b93a2b8807adabec02ef33cca838e30f109c3eba

> --
>   Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>   EDB                                      https://enterprisedb.com
>
>   Do not let urgent matters crowd out time for investment in the future.
>
>

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Ron Johnson <ronljohnsonjr@gmail.com> — 2026-05-14T18:03:53Z

On Thu, May 14, 2026 at 1:55 PM Josef Šimánek <josef.simanek@gmail.com>
wrote:
[snip]

> I think David is back and no fork is needed currently.
>
> https://github.com/pgbackrest/pgbackrest/commit/b93a2b8807adabec02ef33cca838e30f109c3eba



xkcd 2347

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

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Josef Šimánek <josef.simanek@gmail.com> — 2026-05-14T18:06:00Z

čt 14. 5. 2026 v 20:04 odesílatel Ron Johnson <ronljohnsonjr@gmail.com> napsal:
>
> On Thu, May 14, 2026 at 1:55 PM Josef Šimánek <josef.simanek@gmail.com> wrote:
> [snip]
>>
>> I think David is back and no fork is needed currently.
>> https://github.com/pgbackrest/pgbackrest/commit/b93a2b8807adabec02ef33cca838e30f109c3eba
>
>
>
> xkcd 2347

quoting from the message

"We should also be able to bring on another maintainer to distribute
the workload and provide continuity in the future." to prevent that
:pray:

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

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Bruce Momjian <bruce@momjian.us> — 2026-05-14T19:56:38Z

On Thu, May 14, 2026 at 07:54:30PM +0200, Josef Šimánek wrote:
> čt 14. 5. 2026 v 19:26 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
> >
> > On Sun, May 3, 2026 at 11:45:53PM -0700, Christophe Pettus wrote:
> > >
> > >
> > > > 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-sported fork will emerge if there were an existence proof
> > > of it happening in the PostgreSQL community.  I can't think of one.
> >
> > That happened with pgbouncer where development stopped and a new team
> > picked it up.  I think Peter Eisentraut was involved.  With pgbackrest,
> > I think a similar thing would need to happen, but with a new name.
> 
> I think David is back and no fork is needed currently.
> https://github.com/pgbackrest/pgbackrest/commit/b93a2b8807adabec02ef33cca838e30f109c3eba

Well, the pgbackrest website doesn't say that:

	https://pgbackrest.org/

I thought updating that would have been the first thing done if the
status changed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Josef Šimánek <josef.simanek@gmail.com> — 2026-05-14T20:10:41Z

čt 14. 5. 2026 v 21:56 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
>
> On Thu, May 14, 2026 at 07:54:30PM +0200, Josef Šimánek wrote:
> > čt 14. 5. 2026 v 19:26 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
> > >
> > > On Sun, May 3, 2026 at 11:45:53PM -0700, Christophe Pettus wrote:
> > > >
> > > >
> > > > > 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-sported fork will emerge if there were an existence proof
> > > > of it happening in the PostgreSQL community.  I can't think of one.
> > >
> > > That happened with pgbouncer where development stopped and a new team
> > > picked it up.  I think Peter Eisentraut was involved.  With pgbackrest,
> > > I think a similar thing would need to happen, but with a new name.
> >
> > I think David is back and no fork is needed currently.
> > https://github.com/pgbackrest/pgbackrest/commit/b93a2b8807adabec02ef33cca838e30f109c3eba
>
> Well, the pgbackrest website doesn't say that:
>
>         https://pgbackrest.org/
>
> I thought updating that would have been the first thing done if the
> status changed.

Website was also updated, but seems not deployed.
https://github.com/pgbackrest/website/commit/5516003b0f19900fe702b8afd1bc70bc16fede43
I have reported.

> --
>   Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>   EDB                                      https://enterprisedb.com
>
>   Do not let urgent matters crowd out time for investment in the future.

Re: pgBackRest maintenance (was Re: Tablespace size in TB)

Josef Šimánek <josef.simanek@gmail.com> — 2026-05-15T01:09:08Z

čt 14. 5. 2026 v 22:10 odesílatel Josef Šimánek
<josef.simanek@gmail.com> napsal:
>
> čt 14. 5. 2026 v 21:56 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
> >
> > On Thu, May 14, 2026 at 07:54:30PM +0200, Josef Šimánek wrote:
> > > čt 14. 5. 2026 v 19:26 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
> > > >
> > > > On Sun, May 3, 2026 at 11:45:53PM -0700, Christophe Pettus wrote:
> > > > >
> > > > >
> > > > > > 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-sported fork will emerge if there were an existence proof
> > > > > of it happening in the PostgreSQL community.  I can't think of one.
> > > >
> > > > That happened with pgbouncer where development stopped and a new team
> > > > picked it up.  I think Peter Eisentraut was involved.  With pgbackrest,
> > > > I think a similar thing would need to happen, but with a new name.
> > >
> > > I think David is back and no fork is needed currently.
> > > https://github.com/pgbackrest/pgbackrest/commit/b93a2b8807adabec02ef33cca838e30f109c3eba
> >
> > Well, the pgbackrest website doesn't say that:
> >
> >         https://pgbackrest.org/
> >
> > I thought updating that would have been the first thing done if the
> > status changed.
>
> Website was also updated, but seems not deployed.
> https://github.com/pgbackrest/website/commit/5516003b0f19900fe702b8afd1bc70bc16fede43
> I have reported.

site is updated now https://pgbackrest.org/

> > --
> >   Bruce Momjian  <bruce@momjian.us>        https://momjian.us
> >   EDB                                      https://enterprisedb.com
> >
> >   Do not let urgent matters crowd out time for investment in the future.