# towards pg\_staging 1.0

DevFeed: [towards pg\_staging 1.0](<https://devfeed.tech/articles/towards-pg-staging-1-0-34408.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2011/03/towards-pg_staging-1.0/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2011-03-29T13:30:00Z

Content type: article

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Development](<https://devfeed.tech/topics/development.md>), [backups](<https://devfeed.tech/topics/backups.md>)

Tags: [backup](<https://devfeed.tech/tags/backup.md>), [databases](<https://devfeed.tech/tags/databases.md>), [development](<https://devfeed.tech/tags/development.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>)

## AI overview

This article describes pg_staging, a central console for managing PostgreSQL databases in development and pre-production environments. It explains its restore workflow, including fetching backups, filtering objects, running SQL scripts, invoking pg_restore, optionally running VACUUM ANALYZE, and switching the active database.

## Source excerpt

If you don't remember about what pg_staging is all about, it's a central console from where to control all your PostgreSQL databases. Typically you use it to manage your development and pre-production setup, where developers ask you pretty often to install them some newer dump from the production, and you want that operation streamlined and easy. Usage The typical session would be something like this: pg_staging> databases foodb.dev foodb foodb_20100824 :5432 foodb_20100209 foodb_20100209 :5432 foodb_20100824 foodb_20100824 :5432 pgbouncer pgbouncer :6432 postgres postgres :5432 pg_staging> dbsizes foodb.dev foodb.dev foodb_20100209: -1 foodb_20100824: 104 GB Total = 104 GB pg_staging> restore foodb.dev ... pg_staging> switch foodb.dev today The list of supported commands is quite long now, and documented too (it comes with two man pages). The restore one is the most important and will create the database, add it to the pgbouncer setup, fetch the backup named dbname.date -I.dump, prepare a filtered object list (more on that), load pre SQL scripts, launch pg_restore, VACUUM ANALYZE the database when configured to do so, load the post SQL scripts then optionaly switch the pgbouncer setup to default to this new database.