Supported tags and respective
For more information about this image and its history, please see the relevant manifest file (
library/postgres). This image is updated via pull requests to the
docker-library/official-images GitHub repo.
For detailed information about the virtual/transfer sizes and individual layers of each of the above supported tags, please see the
repos/postgres/tag-details.md file in the
docker-library/repo-info GitHub repo.
What is PostgreSQL?
PostgreSQL, often simply "Postgres", is an object-relational database management system (ORDBMS) with an emphasis on extensibility and standards-compliance. As a database server, its primary function is to store data, securely and supporting best practices, and retrieve it later, as requested by other software applications, be it those on the same computer or those running on another computer across a network (including the Internet). It can handle workloads ranging from small single-machine applications to large Internet-facing applications with many concurrent users. Recent versions also provide replication of the database itself for security and scalability.
PostgreSQL implements the majority of the SQL:2011 standard, is ACID-compliant and transactional (including most DDL statements) avoiding locking issues using multiversion concurrency control (MVCC), provides immunity to dirty reads and full serializability; handles complex SQL queries using many indexing methods that are not available in other databases; has updateable views and materialized views, triggers, foreign keys; supports functions and stored procedures, and other expandability, and has a large number of extensions written by third parties. In addition to the possibility of working with the major proprietary and open source databases, PostgreSQL supports migration from them, by its extensive standard SQL support and available migration tools. And if proprietary extensions had been used, by its extensibility that can emulate many through some built-in and third-party open source compatibility extensions, such as for Oracle.
How to use this image
start a postgres instance
$ docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
This image includes
EXPOSE 5432 (the postgres port), so standard container linking will make it automatically available to the linked containers. The default
postgres user and database are created in the entrypoint with
The postgres database is a default database meant for use by users, utilities and third party applications.
connect to it from an application
$ docker run --name some-app --link some-postgres:postgres -d application-that-uses-postgres
... or via
$ docker run -it --rm --link some-postgres:postgres postgres psql -h postgres -U postgres psql (9.5.0) Type "help" for help. postgres=# SELECT 1; ?column? ---------- 1 (1 row)
The PostgreSQL image uses several environment variables which are easy to miss. While none of the variables are required, they may significantly aid you in using the image.
This environment variable is recommended for you to use the PostgreSQL image. This environment variable sets the superuser password for PostgreSQL. The default superuser is defined by the
POSTGRES_USER environment variable. In the above example, it is being set to "mysecretpassword".
This optional environment variable is used in conjunction with
POSTGRES_PASSWORD to set a user and its password. This variable will create the specified user with superuser power and a database with the same name. If it is not specified, then the default user of
postgres will be used.
This optional environment variable can be used to define another location - like a subdirectory - for the database files. The default is
/var/lib/postgresql/data, but if the data volume you're using is a fs mountpoint (like with GCE persistent disks), Postgres
initdb recommends a subdirectory (for example
/var/lib/postgresql/data/pgdata ) be created to contain the data.
This optional environment variable can be used to define a different name for the default database that is created when the image is first started. If it is not specified, then the value of
POSTGRES_USER will be used.
This optional environment variable can be used to send arguments to
postgres initdb. The value is a space separated string of arguments as
postgres initdb would expect them. This is useful for adding functionality like data page checksums:
How to extend this image
If you would like to do additional initialization in an image derived from this one, add one or more
*.sh scripts under
/docker-entrypoint-initdb.d (creating the directory if necessary). After the entrypoint calls
initdb to create the default
postgres user and database, it will run any
*.sql files and source any
*.sh scripts found in that directory to do further initialization before starting the service.
For example, to add an additional user and database, add the following to
#!/bin/bash set -e psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-EOSQL CREATE USER docker; CREATE DATABASE docker; GRANT ALL PRIVILEGES ON DATABASE docker TO docker; EOSQL
These initialization files will be executed in sorted name order as defined by the current locale, which defaults to
*.sql files will be executed by
POSTGRES_USER, which defaults to the
postgres superuser. It is recommended that any
psql commands that are run inside of a
*.sh script be executed as
POSTGRES_USER by using the
--username "$POSTGRES_USER" flag. This user will be able to connect without a password due to the presence of
trust authentication for Unix socket connections made inside the container.
You can also extend the image with a simple
Dockerfile to set a different locale. The following example will set the default locale to
FROM postgres:9.4 RUN localedef -i de_DE -c -f UTF-8 -A /usr/share/locale/locale.alias de_DE.UTF-8 ENV LANG de_DE.utf8
Since database initialization only happens on container startup, this allows us to set the language before it is created.
If there is no database when
postgres starts in a container, then
postgres will create the default database for you. While this is the expected behavior of
postgres, this means that it will not accept incoming connections during that time. This may cause issues when using automation tools, such as
fig, that start several containers simultaneously.
Supported Docker versions
This image is officially supported on Docker version 1.12.2.
Support for older versions (down to 1.6) is provided on a best-effort basis.
Please see the Docker installation documentation for details on how to upgrade your Docker daemon.
If you have any problems with or questions about this image, please contact us on the mailing list or through a GitHub issue. If the issue is related to a CVE, please check for a
cve-tracker issue on the
official-images repository first.
You can also reach many of the official image maintainers via the
#docker-library IRC channel on Freenode.
You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can.
Before you start to code, we recommend discussing your plans on the mailing list or through a GitHub issue, especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing.
Documentation for this image is stored in the
postgres/ directory of the
docker-library/docs GitHub repo. Be sure to familiarize yourself with the repository's
README.md file before attempting a pull request.
I want to create a ostgresql streaming replication between n numbers of servers where my master servers will be in Vm's(differt locations) and all slave servers in docker containers(single) can it is possible?
i am going to use latest PostgreSQL and Docker Version.
Having problems with "long" queries, such as:
INSERT INTO schema,table VALUES (1111111, 1111, 'whatever'), (111111112, 22222, 'any other'), ... with 200+ lines
The 209 lines give a string length of 8746 characters. Unable to execute via psql, pgAdmin or using a .NET application.
Is there any limit (using local postgres works just fine)?
How can I connect from host ?
can i commit this image with a new one without getting loaded data lost?
Recently after I restarted the system with no differences in the DB container running the Postgres image I got the no space left error: "FATAL: could not write lock file "postmaster.pid": No space left on device"
Any ideas about what is causing it?
Need to get this on alpine :) 3.4 now has support for 9.5
Will you build official image on alpine?
It's not possible to restore database backups to this image because pg_restore is broken.
It segfaults in every available version of the image.
root@bb3867e86a83:/# pg_restore -cC /tmp/db.dump
Segmentation fault (core dumped)
For pgAdmin to connect to container, port 5432 needs to be
docker run --name containername -e POSTGRES_PASSWORD=postgrespaswdyoulike -d -p 5432:5432 postgres:9