Postgresql субд

Архитектура PostgreSQL

Одной из наиболее сильных сторон СУБД PostgreSQL является архитектура. Как и в случаях со многими коммерческими СУБД, PostgreSQL можно применять в среде клиент-сервер — это предоставляет множество преимуществ и пользователям, и разработчикам.

В основе PostgreSQL — серверный процесс базы данных, выполняемый на одном сервере. Также стоит сказать, что в Postgres пока не реализована технология высокой готовности, как это сделано в ряде других коммерческих систем управления базами данных уровня предприятия (они способны распределять нагрузку между некоторым количеством серверов, достигая дополнительной масштабируемости и повышенной устойчивости к внешним воздействиям).

Доступ из приложений к данным базы PostgreSQL производится с помощью специального процесса базы данных. То есть клиентские программы не могут получать самостоятельный доступ к данным даже в том случае, если они функционируют на том же ПК, на котором осуществляется серверный процесс.

Таким образом мы получаем разделение клиентов и сервера, что даёт возможность создавать распределённые системы. К примеру, мы можем отделить клиентов от сервера с помощью сети, разрабатывая клиентские приложения в среде, которая удобна для пользователя. Допустим, появляется возможность реализовать базу данных под UNIX, создав клиентские приложения, которые станут работать в ОС Microsoft Windows.

Давайте посмотрим на типичную модель распределенного приложения СУБД PostgreSQL:

Мы видим, что несколько клиентов подсоединены к серверу по сети. СУБД PostgreSQL ориентирована на протокол TCP/IP (локальная сеть либо Интернет), при этом каждый клиент соединён с главным серверным процессом БД (на схеме этот процесс называют Postmaster). Именно Postmaster создаёт новый серверный процесс специально в целях обслуживания запросов на доступ к данным определённого клиента.

Так как манипулирование с данными сосредотачивается на сервере, СУБД PostgreSQL не приходится контролировать многочисленных клиентов, которые получают доступ в совместно используемый серверный каталог. В результате база данных PostgreSQL способна поддерживать целостность данных даже в случае одновременного доступа большого числа пользователей.

Соединение с базой данных клиентских приложений осуществляется по специальному протоколу СУБД PostgreSQL. В принципе, никто не мешает инсталлировать на стороне клиента ПО, предоставляющее стандартный интерфейс, обеспечивающий работу с нужным приложением, допустим, по стандарту ODBC/JDBC. И это хорошо, ведь доступность ODBC-драйвера даёт возможность использовать СУБД PostgreSQL в качестве базы данных для множества уже существующих приложений, включая продукты Microsoft Office — Excel и Access.

Идём дальше. Клиент-серверная архитектура, реализованная в СУБД PostgreSQL, делает возможным разделение труда. То есть машина-сервер прекрасно подходит для хранения и управления доступом к огромным объёмам данных, то есть её можно использовать в качестве надёжного репозитория. При этом для клиентов возможна разработка сложных графических приложений. Также можно создать внешний онлайн-интерфейс, предоставляющий доступ к данным и возвращающий результат в виде web-страниц в стандартный web-браузер, не требуя при этом никакого дополнительного клиентского ПО.

Our users us

Etsy is the sum total of its data, so when it came to choosing where to store our critical information there was only one sound choice. PostgreSQL’s strong emphasis on quality, stability, and data integrity contribute to making it the premier open source database.

The Etsy Development Team, Etsy.com

«PostgreSQL handles virtually all the standard SQL constructs. It is easy (relatively speaking) to administer, it is fast, it is efficient, it has a great API, and it supports ODBC, why would you choose something else?»

Mark Woodward, Mohawk Software

Good software with good services makes us very satisfied with our choice of PostgreSQL and free software.

Clarice Coppetti, IT Vice President, CAIXA Bank, Brazil

«Our systems are deployed in high-availability environments and the combination of PostgreSQL on Linux has enabled us to deploy and support systems without any need for a large support team.»

Tim Allen, Senior Software Developer, Proximity Group

OpenERP has always relied on the enterprise-class features of PostgreSQL to provide a fast, reliable and scalable foundation for the Business Applications supporting our customers’ operations every day.

Olivier Dony, OpenERP Community Manager

2019

Включение в продукты DeviceLock

22 октября 2019 года стало известно, что DeviceLock включил в свои продукты поддержку Postgres Pro и PostgreSQL. Подробнее .

Запуск программы сертификации специалистов по СУБД PostgreSQL

21 мая 2019 года Postgres Professional сообщил о запуске программы сертификации специалистов по СУБД PostgreSQL.

Программа сертификации предусматривает три уровня с возрастающей квалификацией:

1. «Профессионал»
2. «Эксперт»
3. «Мастер»

Для получения сертификата необходимо пройти тестирование в офисе компании Postgres Professional и набрать проходной балл. Материалом для подготовки могут служить авторские курсы Postgres Professional, доступные на сайте, а также регулярно читаемые в сертифицированных учебных центрах. Ежегодно слушателями курсов становятся более 500 человек.

Тест для первого уровня — «Профессионал» — включает в себя 50 вопросов по основам администрирования PostgreSQL и длится 75 минут. Поскольку для каждого релиза PostgreSQL характерны свои особенности администрирования, сертификация соотносится с конкретной версией СУБД. Например, на май 2019 года доступен тест для 10-ой версии PostgreSQL DBA1-10. Для прошедших тестирование на знание PostgreSQL 10 и желающих в будущем подтвердить свои навыки для 11-ой версии достаточно будет пройти короткое дополнительное тестирование, сфокусированное на отличиях продуктов.

Для получения сертификата уровня «Эксперт» понадобится успешно пройти уже три теста:

1. DBA2-10 (настройка и мониторинг PostgreSQL)
2. DBA3-10 (резервное копирование и репликация PostgreSQL)
3. QPT-10 (оптимизация запросов)

А переход на уровень «Мастер» предполагает выполнение практических заданий по работе с PostgreSQL. В дальнейших планах компании Postgres Professional – запуск программы сертификации для разработчиков приложений на PostgreSQL.

Иван Панченко прокомментировал запуск программы сертификации:

Специалисты по Postgres становятся все более востребованными на российском рынке, что подтверждают данные кадровых агентств. В такой ситуации необходимы единые стандарты и критерии для оценки уровня знаний. Во многом наша программа сертификации стала ответом на запросы заказчиков и партнеров, заинтересованных в независимом инструменте оценки и повышения квалификации своих сотрудников. Иван Панченко, заместитель генерального директора Postgres Professional

Совместимость с Live Universal Interface

15 апреля 2019 года компания ФОРС Телеком сообщила о появлении в экосистеме программно-инструментальных средств, совместимых с открытой платформой Postgres Pro/PostgreSQL конструктора пользовательских веб-интерфейсов к базам данных — Live Universal Interface (LUI). Подробнее здесь.

Совместимость с TerraLink xDE

12 марта 2019 года TerraLink сообщил, что TerraLink xDE поддерживает OC семейства Linux и СУБД PostgreSQL. Подробнее .

Тестирование

В какой-то момент задумались, а может, нам страсть к Postgres на Linux застила глаза, и нам только кажется, что все хорошо работает. Решили попробовать подтвердить, что работает как минимум не хуже чем с MS SQL, а может быть, если и хуже-то, то совсем чуть-чуть.

На самом деле, когда приступали к нагрузочному тестированию, вся моя команда, скрестив пальчики думала, ладно, пусть Postgres проиграет, но проиграет не сильно. Все-таки он еще новенький, может быть, нами еще не до конца изученный, но очень активно развивается, и как рассказывал Олег Бартунов, будет очень много крутых фишек в версиях 10 в 11.

На момент организации нашего батла была версия 9. И мы решили, что площадкой для батла будет Windows 2012 R2. Почему Windows? Это для того чтобы соревнование было совсем честным, не учитывая операционные системы, просто проверка двух баз данных.

Итак, в красном углу ринга – заслуженный чемпион, обладатель всех поясов производительности 1С, имеющий любые регалии в мире 1С – Microsoft SQL server версия 2016, последняя поддерживаемая на данный момент.

В синем углу ринга – наш новичок, претендент, PostgreSQL. Он выступает сразу двумя бойцами, каждый бьется по очереди. Это Postgres 9.6 и Postgres 10. Обе версии на данный момент поддерживаются 1С.

Платформа взята последняя релизная на момент тестирования. Все сервера баз данных располагаются на одном и том же железе, это прямо одна и та же коробочка. Все настроено оптимально: и дисковые подсистемы, и процессор, и сервера баз данных (оптимально, согласно требованиям фирмы 1С и нашему опыту). Плюс к этому все настроено на многопользовательскую нагрузку, в том числе параллелизм отключен: и на MS SQL, и на Postgres стоят единички.

О продукте

PostgreSQL поддерживается на всех современных Unix системах (34 платформы), включая наиболее распространенные, такие как Linux, FreeBSD, NetBSD, OpenBSD, SunOS, Solaris, DUX, а также под macOS. Начиная с версии 8.X PostgreSQL работает в «native» режиме под MS Windows NT, Win2000, WinXP, Win2003. Известно, что есть успешные попытки работать с PostgreSQL под Novell Netware 6 и OS2.

PostgreSQL неоднократно признавалась базой года, например, Linux New Media AWARD 2004, 2003 Editors’ Choice Awards, 2004 Editors’ Choice Awards.

PostgreSQL используется как полигон для исследований нового типа баз данных, ориентированных на работу с потоками данных — это проект TelegraphCQ, стартовавший в 2002 году в Беркли после успешного проекта Telegraph (название главной улицы в Беркли).

Два важных момента

Хочу обратить еще внимание на два небольших досадных недоразумения, которые пока есть еще в Postgres. Первое недоразумение – это такой параметр по настройке default_statistics_target

Это своеобразный множитель количества страниц, который берет Postgres для расчета статистики. Он этот множитель умножает на 300 и берет такое количество страниц. Множитель может иметь значение от 1 до 10 тысяч, по умолчанию 100. Все хорошо работает при сотке. Но как только мы ставим 10 тысяч, Postgres, действительно, берет много страниц, считает статистику, но потом запросы к базе начинают резко тормозить. К разработчикам мы еще с этим не обращались, вот-вот обратимся, думаю, победим и разберемся.

Второй момент – это репликация

Просто обращу ваше внимание. Разработчики говорят: репликации – это не бэкап

Это действительно так. Кроме того, репликация может отставать на часы и дни. Потому что она однопоточная. Все, что мастер-сервер удалил, создал, обновил в сотне своих потоков, все это придется догонять в один поток. Поэтому реплика это хорошо, мы, например, с нее бэкапы льем, но перед тем, как слить бэкап с реплики, мы проверяем какое отставание. Если отставание не больше секунды, то делаем бэкап с нее, а если больше – то с мастера.

В завершение хочу сказать, что, привлекая компетентных специалистов, вы можете зарабатывать золотые медали любых тестов 1С. Даже на таком новичке в мире 1С, как Postgres, выбирая правильную инфраструктуру.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Первый раунд

В первом раунде тяжелая операция – загрузка DT 40 с лишним гигабайт, итоговая база почти 2 терабайта. Сразу оговорюсь, если заглянуть в интернет, там будет много информации о том, что в DT не выгружается база, потому что она более 100 гигабайт, и ничего не работает. Все работает, надо только правильно настраивать сервер 1С, надо понимать, куда сервер 1С выгружает DT. Подтверждаю на своем опыте: база до 5 терабайт (больше не приходилось выгружать) из DT загружается и в DT выгружается. Все остальное – это неумение настраивать сервера 1С.

Первые результаты. С явным преимуществом побеждает MS SQL. Он в 2 раза быстрее загрузил данные в DT. Оба загружали очень долго, Postgres – почти двое суток, а MS SQL – почти сутки.

В то время как раз был шум про мельдоний (скандал в СМИ), и мы тоже решили обратиться к допингу. Решили использовать топ вредных советов из интернета на запрос «1С + Postgres тормозит». Первый совет – отключить fsync. Отключили. Получили другой результат – на 10% быстрее, чем с включенным, но риски несоизмеримы. Потому что такое отключение приведет к потере всего сервера баз данных. Вы не сможете ничего восстановить при аварийном завершении. Никогда так не делайте! Это самый вредный совет, который только может быть. Если вдруг вам действительно помогло отключение fsync, и все заработало в 10 раз быстрее, Это значит что у вас сервер неправильно настроен, начиная с самого низкого уровня – с железа, с дисками.

Fsync отключать нельзя никогда!

Но что такое есть в Postgres, что он загружает данные в DT в 2 раза дольше? Наши исследования показали, что это «create index». Он создает индексы намного медленнее MS. В начале 2018 года разработчики обещали, что в версии 12 эта ситуация улучшится. Ждем с нетерпением, думаю, тогда даже в этом раунде мы будем близки к MS SQL.

PostgreSQL 11.0 -> 12.0

Фича
Риск
Кому обратить внимание
Комментарий
Изменение поведения функции , вызываемой в стиле SQL, на соответствующее стандарту, «жадное» (Том Лейн)
В случаях, когда искомый шаблон может быть выбран в строке несколькими способами, начальному сегменту шаблона сопоставляется не наибольшая, а наименьшая подстрока; например, шаблон теперь выбирает из входной строки не последнее, а первое вхождение ряда a.
Нарушение работы приложения
Разработчик
Серьезное нарушение совместимости, которое может быть оправдано только тем, что привели функциональность в соответствие со стандартом SQL. Если кто-то использует функцию с паттернами, то необходимо вдумчиво проверить, так как это может привести к труднопредсказуемым последствиям
Проблемы могут оказаться как на стороне БД, так и в запросах со стороны клиента.
Перенос параметров в (Масао Фудзии, Саймон Риггс, Абхиджит Менон-Сен, Сергей Корнилов)
Файл более не используется, и сервер не запустится, если обнаружит его. Теперь для переключения сервера из режима ведущего используются файлы и . Параметр был переименован в , а параметр удалён.
Нарушение работы приложения
Системный администратор

Недопущение конфликта множественных указаний (Питер Эйзентраут)
А именно, допускается только одно из указаний , , , или . Ранее в конфигурации могли присутствовать несколько этих параметров, а действовало только последнее вхождение. Сейчас может задаваться только один, хотя если он задаётся неоднократно, действует так же только последнее указание.
Нарушение работы приложения
Системный администратор

Переход в процессе восстановления по умолчанию к последней линии времени (Питер Эйзентраут)
То есть параметр теперь имеет значение по умолчанию . Ранее подразумевалось значение .
Нарушение работы приложения
Системный администратор

Переименование утилиты командной строки в (Микаэль Пакье)
Нарушение работы приложения
Системный администратор

Добавление в требования ключа — для получения содержимого дампа через стандартное устройство вывода (Эйлер Тавейра)
Ранее дамп выводился в стандартное устройство вывода и тогда, когда назначение не указывалось, но это было признано нежелательным поведением.
Нарушение работы приложения
Системный администратор

Недопущение неоднозначных сокращений в команде утилиты psql (Даниэль Верите)
Ранее, например, при вводе команды выбирался вариант ; однако возможен и вариант , поэтому теперь не будет выбираться никакой.
Нарушение работы приложения
Системный администратор
Изменения в формате внутри команды . Теоретически, это может коснуться системных администраторов или тех, кто работает с БД через и использует .
В новых индексах btree максимальный размер записи индекса сокращён на 8 байт с целью усовершенствования обработки повторяющихся элементов (Питер Гейган)
Вследствие этого при выполнении с индексом, полученным в результате обновления предыдущей версии с применением , может возникнуть ошибка.
Нарушение работы приложения
Системный администратор
Касается только системных администраторов

Важное замечание, которое обязательно должно быть учтено. Подробнее мы написали в начале, когда рассуждали о разных способах апгрейда

Еще один аргумент не в пользу .
Удаление возможности отключения динамической общей памяти (Кётаро Хоригути)
Таким образом, параметр теперь не может принимать значение none.
Нарушение работы приложения
Системный администратор

Автоматическое встраивание в запрос общих табличных выражений (CTE), с возможностью переопределения этого поведения
Падение производительности
Разработчик
В официальной документации эта фича не помечена как несовместимая. Но, как мудро заметил Олег Бартунов, тут возможны проблемы при портировании, только не функциональные, а связанные с производительностью. В 12-й версии обычные CTE из старых версий будут больше подвержены оптимизации планировщика. Теоретически это только в плюс, и производительность, скорее всего, вырастет. Но если планировщик не отрабатывает должным образом, это сможет привести к драматическому падению производительности.Для контроля и быстрого реагирования на проблемы производительности желательно, чтобы был установлен заранее на все БД. Удобнее всего это сделать, добавив его в .

Настройки на Master

В данной статье мы будем настраивать серверы с IP-адресами 192.168.1.10 (первичный или master) и 192.168.1.11 (вторичный или slave).

Переходим на сервер, с которого будем реплицировать данные (мастер) и выполняем следующие действия.

Создаем пользователя в PostgreSQL

Входим в систему под пользователем postgres:

su — postgres

Создаем нового пользователя для репликации:

createuser —replication -P repluser

* система запросит пароль — его нужно придумать и ввести дважды. В данном примере мы создаем пользователя repluser.

Выходим из оболочки пользователя postgres:

exit

Настраиваем postgresql

Смотрим расположение конфигурационного файла postgresql.conf командой:

su — postgres -c «psql -c ‘SHOW config_file;'»

В моем случае система вернула строку:

 /etc/postgresql/9.6/main/postgresql.conf

* конфигурационный файл находится по пути /etc/postgresql/9.6/main/postgresql.conf.

Открываем конфигурационный файл postgresql.conf.

vi /etc/postgresql/9.6/main/postgresql.conf

* мы открываем файл, который получили sql-командой SHOW config_file;.

Редактируем следующие параметры:

listen_addresses = ‘localhost, 192.168.1.10’
wal_level = replica
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on

* где

• 192.168.1.10 — IP-адрес сервера, на котором он будем слушать запросы Postgre; 
• wal_level указывает, сколько информации записывается в WAL (журнал операций, который используется для репликации); 
• max_wal_senders — количество планируемых слейвов; 
• max_replication_slots — максимальное число слотов репликации (данный параметр не нужен для postgresql 9.2 — с ним сервер не запустится); 
• hot_standby — определяет, можно или нет подключаться к postgresql для выполнения запросов в процессе восстановления; 
• hot_standby_feedback — определяет, будет или нет сервер slave сообщать мастеру о запросах, которые он выполняет.

Открываем конфигурационный файл pg_hba.conf — он находитсяч в том же каталоге, что и файл postgresql.conf:

vi /etc/postgresql/9.6/main/pg_hba.conf

Добавляем следующие строки:

host replication repluser 127.0.0.1/32 md5
host replication repluser 192.168.1.10/32 md5
host replication repluser 192.168.1.11/32 md5

* данной настройкой мы разрешаем подключение к базе данных replication пользователю repluser с локального сервера (localhost и 192.168.1.10) и сервера 192.168.1.11.

Перезапускаем службу postgresql:

systemctl restart postgresql

* обратите внимание, что название для сервиса в системах Linux может различаться

7.8.2. Data-Modifying Statements in WITH

You can use data-modifying statements (INSERT, UPDATE, or
DELETE) in WITH. This allows you to perform several
different operations in the same query. An example is:

WITH moved_rows AS (
    DELETE FROM products
    WHERE
        "date" >= '2010-10-01' AND
        "date" < '2010-11-01'
    RETURNING *
)
INSERT INTO products_log
SELECT * FROM moved_rows;

This query effectively moves rows from products to products_log. The DELETE in WITH deletes
the specified rows from products,
returning their contents by means of its RETURNING clause; and then the primary query
reads that output and inserts it into products_log.

A fine point of the above example is that the WITH clause is attached to the INSERT, not the sub-SELECT within the INSERT. This is necessary because data-modifying
statements are only allowed in WITH
clauses that are attached to the top-level statement. However,
normal WITH visibility rules apply, so
it is possible to refer to the WITH
statement’s output from the sub-SELECT.

Data-modifying statements in WITH
usually have RETURNING clauses, as
seen in the example above. It is the output of the RETURNING clause, not the target table of the
data-modifying statement, that forms the temporary table that
can be referred to by the rest of the query. If a
data-modifying statement in WITH lacks
a RETURNING clause, then it forms no
temporary table and cannot be referred to in the rest of the
query. Such a statement will be executed nonetheless. A
not-particularly-useful example is:

WITH t AS (
    DELETE FROM foo
)
DELETE FROM bar;

This example would remove all rows from tables foo and bar. The
number of affected rows reported to the client would only
include rows removed from bar.

Recursive self-references in data-modifying statements are
not allowed. In some cases it is possible to work around this
limitation by referring to the output of a recursive WITH, for example:

WITH RECURSIVE included_parts(sub_part, part) AS (
    SELECT sub_part, part FROM parts WHERE part = 'our_product'
  UNION ALL
    SELECT p.sub_part, p.part
    FROM included_parts pr, parts p
    WHERE p.part = pr.sub_part
  )
DELETE FROM parts
  WHERE part IN (SELECT part FROM included_parts);

This query would remove all direct and indirect subparts of
a product.

Data-modifying statements in WITH
are executed exactly once, and always to completion,
independently of whether the primary query reads all (or indeed
any) of their output. Notice that this is different from the
rule for SELECT in WITH: as stated in the previous section,
execution of a SELECT is carried only
as far as the primary query demands its output.

The sub-statements in WITH are
executed concurrently with each other and with the main query.
Therefore, when using data-modifying statements in WITH, the order in which the specified updates
actually happen is unpredictable. All the statements are
executed with the same snapshot (see
Chapter 13), so they cannot
«see» one another’s effects on the
target tables. This alleviates the effects of the
unpredictability of the actual order of row updates, and means
that RETURNING data is the only way to
communicate changes between different WITH sub-statements and the main query. An
example of this is that in

WITH t AS (
    UPDATE products SET price = price * 1.05
    RETURNING *
)
SELECT * FROM products;

the outer SELECT would return the
original prices before the action of the UPDATE, while in

WITH t AS (
    UPDATE products SET price = price * 1.05
    RETURNING *
)
SELECT * FROM t;

the outer SELECT would return the
updated data.

Trying to update the same row twice in a single statement is
not supported. Only one of the modifications takes place, but
it is not easy (and sometimes not possible) to reliably predict
which one. This also applies to deleting a row that was already
updated in the same statement: only the update is performed.
Therefore you should generally avoid trying to modify a single
row twice in a single statement. In particular avoid writing
WITH sub-statements that could affect
the same rows changed by the main statement or a sibling
sub-statement. The effects of such a statement will not be
predictable.

At present, any table used as the target of a data-modifying
statement in WITH must not have a
conditional rule, nor an ALSO rule,
nor an INSTEAD rule that expands to
multiple statements.

Поддержка стандартов, возможности, особенности

PostgreSQL
PostgreSQL поддерживает большинство возможностей стандарта SQL: 2011, ACID-совместимая и транзакционная (включая большинство DDL утверждения) избегает проблемы блокировки с помощью механизма Многоверсионное управление параллельным доступом (MVCC), обеспечивает иммунитет к «грязному» чтению и полую сериализационность; управляет комплексными SQL запросами используя множество индексированных методов, которые недоступны в других базах данных; имеет обновляемые представления и материализованные представления, триггеры, внешние ключи; поддерживает функции и хранимые процедуры, и другие возможности расширения, и имеет множество расширений, написанных третьими лицами. В дополнение к возможности работы с основными фирменными и с открытым исходным кодом базами данных, PostgreSQL поддерживает миграцию из них, путем своей обширной поддержки стандарта SQL и доступных инструментов миграции. Фирменные расширения в базах данных, таких как Oracle можно эмулировать с помощью встроенных и сторонних расширений совместимости с открытым исходным кодом. Последние версии также обеспечивают репликацию самой базы данных для доступности и масштабируемости.

PostgreSQL является кросплотформенной и работает на множестве операционных систем, включая Linux, FreeBSD, macOS, Solaris, и Microsoft Windows. Начиная с Mac OS X 10.7 Lion Server, PostgreSQL это стандартная база данных по умолчанию, и клиентские инструменты PostgreSQL идут в комплекте с настольной версией. Подавляющее большинство дистрибутивов Linux имеет PostgreSQL доступным в поддерживаемых пакетах.

PostgreSQL разработан PostgreSQL Global Development Group, разнообразной группой из многих компаний и отдельных вкладчиков. Это свободное и открытое программное обеспечение, распространяемое по условиям Лицензии PostgreSQL, разрешительной лицензии свободного программного обеспечения.

Поскольку СУБД PostgreSQL выпускается под либеральной лицензией, её можно бесплатно использовать, модифицировать и распространять для любых целей, включая личные, коммерческие или академические.

На данный момент (версия 9.4.5), в PostgreSQL имеются следующие ограничения:

Максимальный размер базы данных	Нет ограничений
Максимальный размер таблицы	32 Тбайт
Максимальный размер записи	1,6 Тбайт
Максимальный размер поля	1 Гбайт
Максимум записей в таблице	Нет ограничений
Максимум полей в записи	250—1600, в зависимости от типов полей
Максимум индексов в таблице	Нет ограничений

Сильными сторонами PostgreSQL считаются:

• высокопроизводительные и надёжные механизмы транзакций и репликации;
• расширяемая система встроенных языков программирования: в стандартной поставке поддерживаются PL/pgSQL, [PL/Perl, PL/Python и PL/Tcl; дополнительно можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Scheme, PL/sh и PL/V8, а также имеется поддержка загрузки C-совместимых модулей ;
• поддержка со стороны многих языков программирования: C\C++, Java, Perl, Python, Ruby, ECPG, Tcl, PHP и других.
• наследование;
• легкая расширяемость.