Traditionally, databases are large and hosted in silos serving critical applications. These critical-application requirements are still there but I'm starting to see more databases being hosted on the same cluster for the purpose of lower resource overhead. These are generally AI produced tools/applications/reports running on cron jobs that do need persistent stores. I have not seen the scale of 5,000+ databases as mentioned in Parallelizing startup with many databases but I'm seeing the requirement for co-location increasing. This proposed command option can definitely help when working with multi-database clusters.
I think this is a useful addition to vacuumdb and I hope we can get it through. Please let me know if I can be of any assistance. -Khoa On Thu, Jun 18, 2026 at 9:36 AM Khoa Nguyen <[email protected]> wrote: > > On Wed, Jun 17, 2026 at 7:24 PM Ben Mejia > <[email protected]> wrote: > > > > I think that the behavior of this patch that silently ignores > > --exlcude-database "non-existent-db" is broken. What if someone has a large > > database "my-db-name", and they misspell it: > > > > $ vacuumdb --all --exclude-database "my-dbname" > > > > This will kick off a vacuum including the "my-db-name" they were trying to > > exclude. > > > > I think it would be better to generate an error and not do anything in this > > case. > +1 > > Since exclude-schema validates and stops on error, I think it would > make sense to do the same for exclude-database. Current users are > used to this behavior so it's best to keep it consistent. > > > > > This also tracks with vacuumdb's existing behavior on --table/--schema > > which will tell you about a typo.
