PostgreSQL и MySQL — это надежные, безопасные и масштабируемые базы данных, которые существуют уже много лет. Каждая из них имеет уникальные сильные и слабые стороны, что делает какую‑либо из них более подходящей для конкретных нужд. В этой статье мы проведем их сравнение, чтобы помочь с принятием обоснованного решения в 2023 году.

Что касается выбора реляционной системы управления базами данных (РСУБД), то популярны два варианта — PostgreSQL и MySQL. Обе системы существуют уже несколько десятилетий и зарекомендовали себя как надежные, безопасные и масштабируемые. Однако они имеют различные сильные и слабые стороны, что делает одну из них более подходящей для конкретных случаев использования. В этой статье мы сравним PostgreSQL и MySQL, чтобы помочь вам принять обоснованное решение в 2023 году.

История и развитие

PostgreSQL была впервые выпущена в 1996 году и стала широко используемой СУБД с открытым исходным кодом. Она известна своей строгой приверженностью стандартам SQL, широким набором функциональных возможностей, а также вниманием к целостности и безопасности данных.

MySQL, с другой стороны, была впервые выпущена в 1995 году и широко применялась для веб‑приложений благодаря своей высокой производительности и простоте использования. Со временем компания Oracle приобрела систему управления базами данных MySQL с открытым исходным кодом и превратила ее в коммерческий продукт.

Функциональные возможности

PostgreSQL и MySQL предлагают широкий спектр возможностей в качестве систем управления реляционными базами данных, но между ними есть некоторые ключевые различия:

  1. Типы данных: PostgreSQL поддерживает более широкий спектр современных типов данных, включая массивы, hstore (хранилище типа “ключ-значение”) и JSONB (бинарный JSON), которые обеспечивают более гибкие и эффективные возможности хранения данных. С другой стороны, MySQL имеет ограниченный набор типов данных и ориентирован на более простые веб-приложения.

  2. Поддержка геопространственных данных: PostgreSQL поддерживает геопространственные данные, включая богатый набор типов данных, функций и операторов для работы с географическими данными. MySQL, хотя и имеет некоторую поддержку геопространственных данных, мог бы обладать большей функциональной мощью в этой области.

  3. Индексирование: В MySQL по умолчанию используется тип индекса B-tree, который хорошо подходит для большинства юзкейсов. PostgreSQL имеет более совершенную систему индексирования, чем MySQL, включая поддержку индексов B-tree, GiST (Generalized Search Tree. Обобщенное поисковое дерево) и GIN (Generalized Inverted Index. Обобщенный обратный индекс). Они предоставляют больше возможностей для оптимизации производительности запросов и поиска данных.

  4. Репликация: PostgreSQL и MySQL поддерживают репликацию баз данных, но методы и возможности репликации различны. PostgreSQL поддерживает мульти-мастер (с несколькими мастерами) репликацию, в то время как MySQL в основном поддерживает репликацию master-slave (ведущий-ведомый). Недавно MySQL представила новую модель репликации под названием Group Replication (групповая репликация), но это все еще относительно новая фича с некоторыми ограничениями.

  5. Транзакции: PostgreSQL и MySQL InnoDB используют MVCC (Multi-Version Concurrency Control. Многоверсионный контроль параллелизма) для обработки параллельного доступа к данным. Однако PostgreSQL предлагает развитые возможности управления транзакциями, такие как уровни изолированности транзакций, атомарные транзакции и точки сохранения. В отличие от этого, опции по управлению транзакциями в MySQL более ограничены. PostgreSQL может быть лучше для применения в приложениях, требующих высокого параллелизма или сложной логики транзакций.

  6. Хранимые процедуры: PostgreSQL и MySQL поддерживают хранимые процедуры, но язык и функциональность хранимых процедур различны. PostgreSQL поддерживает хранимые процедуры, написанные на различных языках, включая PL/pgSQL, PL/Tcl, PL/Perl и другие. MySQL, напротив, в основном поддерживает хранимые процедуры, написанные на языке SQL.

  7. Расширения: PostgreSQL имеет надежную платформу расширений, которая позволяет разработчикам добавлять пользовательские функции и расширять основные возможности базы данных. Хотя MySQL имеет некоторую поддержку расширений, уровень расширяемости у нее иной, чем у PostgreSQL.

Захват измененных данных

С точки зрения захвата измененных данных (CDC), как бинарные логи MySQL, так и журналы предзаписи (WAL) PostgreSQL могут фиксировать изменения, внесенные в базу данных. Однако конкретные возможности и использование CDC могут отличаться.

DBConvert Streams - это программное обеспечение, которое может читать журналы транзакций MySQL и PostgreSQL и преобразовывать записи в другой диалект, что делает его пригодным для репликации гетерогенных баз данных в режиме реального времени.

Производительность

MySQL известна своей высокой производительностью и способностью обрабатывать большие объемы данных. Она была оптимизирована для рабочих нагрузок с интенсивными операциями чтения данных и имеет быструю систему индексирования, которая помогает улучшить производительность запросов. Однако при выполнении операций записи могут возникать проблемы параллелизма, такие как блокировки, что приводит к снижению производительности. Это связано с реализацией блокировок на уровне таблиц, препятствующих любым действиям во время выполнения операции записи.

Для решения проблемы блокировок на уровне таблиц используется механизм хранения InnoDB. Это один из самых популярных и широко используемых механизмов хранения данных в экосистеме MySQL. InnoDB поддерживает блокировку на уровне строки, улучшая параллелизм для смешанных рабочих нагрузок.

Кроме того, недавняя разработка высокопроизводительного механизма хранения данных MyRocks еще больше улучшила способность MySQL справляться с интенсивными рабочими нагрузками, связанными с записью.

PostgreSQL разработана в качестве более универсальной системы, способной справляться как с рабочими нагрузками при интенсивных операциях чтения, так и при интенсивной записи, но с немного меньшей производительностью, чем MySQL, которая оптимизирована для больших нагрузок во время чтения. Однако в последних версиях PostgreSQL улучшила свою производительность, особенно в отношении сложных запросов и обработки данных.

Кроме того, PostgreSQL имеет более развитую систему индексирования по сравнению с MySQL, что может повысить производительность при выполнении сложных запросов. PostgreSQL также поддерживает расширенные типы данных, такие как массивы и JSONB, что может привести к более эффективному хранению и получению данных.

В конечном итоге, производительность PostgreSQL и MySQL зависит от различных факторов, таких как аппаратное обеспечение, объем данных и сложность запросов.

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

Масштабируемость

И MySQL, и PostgreSQL могут масштабироваться, однако в этом вопросе у них имеются свои сильные и слабые стороны.

MySQL часто предпочитают за ее горизонтальную масштабируемость, это означает, что ее можно масштабировать путем добавления новых узлов в кластер базы данных. Она идеально подходит для веб-приложений, которым необходимо обрабатывать большое количество одновременных соединений.

С другой стороны, PostgreSQL известна своей вертикальной масштабируемостью, то есть она может обрабатывать большие объемы данных и манипулировать вычислительными мощностями путем добавления дополнительных ресурсов, таких как память и процессор, на один узел. Она также поддерживает горизонтальное масштабирование с помощью таких технологий, как шардинг, которая позволяет разделять большие массивы данных на несколько узлов. PostgreSQL предпочтительна для приложений, требующих сложных запросов и транзакций, а также для рабочих задач в области хранения данных и бизнес-аналитики.

Что касается масштабируемости, учитывайте конкретные требования вашего приложения. Если вам необходимо обрабатывать большое количество параллельных соединений и требуется горизонтальная масштабируемость, MySQL может быть лучшим выбором. Однако PostgreSQL больше подходит, когда нужны сложные транзакции и запросы.

Стоимость

В 2023 году PostgreSQL по-прежнему является продуктом с открытым исходным кодом и ориентированной на сообщество, в то время как MySQL имеет более сложную историю лицензирования. MySQL изначально разрабатывалась как коммерческий продукт компанией MySQL AB, причем были доступны бесплатные и платные версии. Покупка MySQL AB компанией Oracle в 2010 году вызвала некоторые опасения среди разработчиков по поводу будущего статуса MySQL с открытым исходным кодом. Однако несколько форков оригинального MySQL с открытым исходным кодом, включая MariaDB и Percona, сняли эти опасения.

Когда использовать MySQL?

Хотя PostgreSQL имеет множество передовых фич и часто считается более продвинутой и сложной системой управления базами данных, чем MySQL, у нее есть свои недостатки.

К общим недостаткам PostgreSQL можно отнести следующие:

  1. Несмотря на свои продвинутые функции и возможности, PostgreSQL еще не достигла того же уровня популярности и широкого использования, что и MySQL. Это привело к меньшему количеству сторонних инструментов, опытных разработчиков и администраторов баз данных в экосистеме PostgreSQL.

  2. Из-за своих расширенных возможностей PostgreSQL может быть сложнее в настройке и управлении, чем MySQL, поэтому она больше подходит для опытных администраторов баз данных и разработчиков.

  3. В некоторых случаях PostgreSQL работает медленнее, чем MySQL, из-за более сложной архитектуры и функций.

  4. PostgreSQL потребляет больше ресурсов, чем MySQL, особенно в плане использования памяти и процессора.

  5. Хотя PostgreSQL поставляется с открытым исходным кодом, стоимость внедрения и обслуживания может быть высокой из-за ее расширенных возможностей и повышенных требований к ресурсам.

  6. PostgreSQL заново запускает еще один процесс для каждого нового клиентского подключения, что приводит к выделению значительного объема памяти, обычно около 10 МБ на соединение. Однако такая архитектура разработана для обеспечения повышенной безопасности и изоляции между различными клиентами и, как правило, считается компромиссом ради повышения производительности, надежности и масштабируемости.

  7. PostgreSQL разработана с учетом приоритетов расширяемости, соответствия стандартам, масштабируемости и целостности данных. Иногда данные фичи могут снижать производительность по сравнению с MySQL, особенно в обычных рабочих нагрузках, связанных с интенсивными операциями чтения. Однако важно отметить, что точное значение разницы в производительности зависит от ряда факторов, таких как размер данных, сложность запросов и используемое оборудование.

Какая миграция более распространена: MySQL на PostgreSQL или PostgreSQL на MySQL?

Частота миграции между MySQL и PostgreSQL различна и зависит от потребностей и требований отдельных организаций. Некоторые организации могут мигрировать с MySQL на PostgreSQL, чтобы воспользоваться ее расширенными возможностями, лучшим соответствием требованиям SQL и совместимостью с открытым исходным кодом. PostgreSQL также более распространена в определенных отраслях, таких как финансовые услуги, государственное управление и хранение данных, где производительность, масштабируемость и безопасность являются важными факторами.

С другой стороны, другие компании могут перейти с PostgreSQL на MySQL из-за ее простоты, широкой поддержки сообщества и более низкой стоимости внедрения.

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

  1. Доступность инструментов миграции: Существует множество бесплатных и коммерческих инструментов миграции, помогающих перенести данные с MySQL на PostgreSQL. При этом инструментов для переноса данных с PostgreSQL на MySQL гораздо меньше.

  2. Онлайн-ресурсы: Существует больше онлайн-учебников и ресурсов по миграции с MySQL на PostgreSQL, чем наоборот.

  3. Рост сообщества: Сообщество PostgreSQL растет быстрее, чем сообщество MySQL, что указывает на повышающийся интерес к использованию PostgreSQL по сравнению с MySQL.

  4. Вложения в открытый исходный код: Увеличивающееся количество вкладов в PostgreSQL с открытым исходным кодом указывает на то, что все больше людей инвестируют время и ресурсы в эту технологию и находят ее полезной для своих нужд.

  5. Внедрение на предприятиях: Некоторые из крупнейших в мире и наиболее требовательных к данным организаций, такие как Cisco, Fujitsu и Федеральная авиационная администрация США (FAA), публично заявили, что перешли с MySQL на PostgreSQL.

  6. Опросы пользователей: Отраслевые аналитики и эксперты по базам данных провели опросы, которые показывают, что все больше людей обдумывают возможность или планируют перейти с MySQL на PostgreSQL.

Эти факты свидетельствуют лишь о том, что с MySQL на PostgreSQL переходят чаще, чем наоборот, и это может быть верно лишь в некоторых случаях.

Заключение

PostgreSQL и MySQL — надежные реляционные системы управления базами данных с уникальными возможностями и ограничениями. Решение об использовании какой‑либо из них должно основываться на конкретных требованиях проекта, таких как характер и объем данных, сложность запросов, а также потребности в производительности и масштабируемости. Поскольку и PostgreSQL, и MySQL в 2023 году ожидает дальнейшее развитие, очень важно быть в курсе их последних разработок.

Кроме того, стоит упомянуть, что такие инструменты, как DBConvert Studio, могут помочь при миграции данных между MySQL и PostgreSQL в любом направлении. Эти инструменты позволяют упростить процесс передачи данных из одной базы данных в другую, что может быть особенно полезно, если вы рассматриваете возможность перехода с одной системы на другую.


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

Комментарии (27)


  1. Bozaro
    00.00.0000 00:00
    +5

    MySQL - это минное поле. У неё куча очень странных особенностей, которые могут вставить нож в спину в самый неожиданный момент.
    Из особо прекрасного: https://www.percona.com/blog/what-if-mysqls-repeatable-reads-cause-you-to-lose-money/
    Ну и, строго говоря, MySQL не является SQL СУБД.


    1. ShefEr
      00.00.0000 00:00
      +7

      Ну и, строго говоря, MySQL не является SQL СУБД.

      Очень интересно почему, можете раскрыть мысль?


      1. Bozaro
        00.00.0000 00:00
        +8

        С моей точки зрения, SQL СУБД должна соответствовать хоть одному SQL-стандарту.
        Должен быть не только похожий синтаксис, но и поведение.

        К примеру, запрос:

        UPDATE foo SET a = b, b = a WHERE  id = 42

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

        Про особенное виденье уровней изоляции транзакций уже было выше.

        Все эти особенности в MySQL документированы и переведены в категорию фичей, но от этого как-то не легче.


        1. Ivan22
          00.00.0000 00:00
          +1

          А что есть в мире субд полностью поддерживающая весь ansi??

          https://docs.oracle.com/database/121/SQLRF/ap_standard_sql003.htm#SQLRF55516

          Вот например список исключений для оракла, там несколько листов


          1. Bozaro
            00.00.0000 00:00
            +3

            Я не знаю СУБД, которые полностью поддерживающая весь ansi.

            Но UPDATE входит в Core SQL Features под номером E101-03. Всё-таки весь стандарт и его Core SQL часть несколько разные вещи :)


    1. Kwisatz
      00.00.0000 00:00
      +13

      А еще оптимизатор запросов у mysql по сравнение с pg - младенец, я знаю тысячи способов завести mysql за угол или оптимизировать запрос и 99% из них не работают и не имеют смысла в пг.

      Вообще уже давно нет ни одной причины брать MySQL кроме страха.

      PS когда то я услышал фразу "PG это база данных, а MySQL это хер с гвоздями", сначала она мне показалась странной, но теперь, я моуг привести пару сотен случаев почему она на 100% правдива.


      1. auresio
        00.00.0000 00:00
        +25

        Так может вы нам пост напишете.
        Я б почитал почему MySQL это хер с гвоздями. :)


        1. Kwisatz
          00.00.0000 00:00
          +2

          Хм, идея интересная, подумаю в апреле. Беда в том что когда я говорю, что знаю сотни случаев, я не преувеличиваю, тут явно надо взять какой то срез а потом просто остановиться, а я так не умею, поэтом обычно выливатся в заготовок статьи а потом жуть страдания и прокрастинация (

          То есть, например проблемы с типами данных на примерах я легко опишу, но вот для описание тупости оптимизатора запросов, нужно будет серьезную доказательную базу создать.

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


  1. paldraken
    00.00.0000 00:00
    +3

    По запросу в гугл "habr postgresql mysql" можно найти многолетнюю историю превосходства postgresql. Но пункт 1 из статьи остается неизменным. )

    Несмотря на свои продвинутые функции и возможности, PostgreSQL еще не достигла того же уровня популярности и широкого использования, что и MySQL.


    1. breninsul
      00.00.0000 00:00
      -1

      Это не правда. Кто сейчас начинает проекты на mysql? Зачем?!


  1. Sysliks
    00.00.0000 00:00
    -4

    сравнение карьерного самосвала и башенного крана


  1. Akina
    00.00.0000 00:00
    +2

    Типы данных: PostgreSQL поддерживает более широкий спектр современных типов данных, включая массивы, hstore (хранилище типа “ключ-значение”) и JSONB (бинарный JSON), которые обеспечивают более гибкие и эффективные возможности хранения данных. С другой стороны, MySQL имеет ограниченный набор типов данных и ориентирован на более простые веб-приложения.

    Данный абзац заставляет думать, что указанные типы данных в MySQL отсутствуют. И если относительно первых двух это верно, то насчёт бинарного JSON - увы, неверно. MySQL хранит данные в поле типа JSON именно в бинарном виде. Простейшим доказательством чего (не считая чтения документации, конечно) может быть пересортировка свойств в объекте по алфавиту. Иными словами, то, что в MySQL обозначено как JSON, является аналогом Постгрессовского JSONB. А вот если надо сохранять данные так, как делает Постгресс в типе данных JSON, то для этого в MySQL придётся использовать тип данных TEXT.


    1. sshikov
      00.00.0000 00:00

      Данный абзац заставляет думать, что указанные типы данных в MySQL отсутствуют.

      А можно в MySQL вообще писать расширения, и добавлять свои типы? В постгресе можно, и PostGIS тому пример.


      Насколько я быстро смог загуглить — нет, вроде нельзя. И в принципе, как по мне, один этот пункт перекрывает многие, если не все другие преимущества, касающиеся именно типов.


      Я бы кстати тоже высказался так: с моей точки зрения сегодня нет никаких причин использовать MySQL, кроме одной: вы его хорошо знаете, и уже на нем работаете. То есть у вас легаси система, которую нет смысла портировать.


      1. Akina
        00.00.0000 00:00

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

        Есть ещё одна возможная причина. Порог входа для MySQL на порядок ниже. То есть он хорошо подходит для самого первого, "с нуля", знакомства. Правда, при условии, что в нём по максимуму отключены lamer-friendly расширения, и особенно - ONLY_FULL_GROUP_BY SQL Made. Иначе потом с него спрыгнуть будет тяжко.


        1. YuryZakharov
          00.00.0000 00:00

          он хорошо подходит для самого первого, "с нуля", знакомства.

          Выглядит, как совет "Сначала покатайся на вазовской классике, когда научишься, купи нормальную машину".


        1. sshikov
          00.00.0000 00:00

          Порог входа для MySQL на порядок ниже.
          Ну, мне конечно сложно оценить, потому что у меня не с нуля ни разу, но PostgreSQL я ставил именно ничего не зная о нем, скачал дистриб, распаковал, запустил, работает. Настройки потом конечно менять надо кое-какие, но у меня и ребенок это может сделать, если что (проверено). То есть, порог входа в PostgreSQL сегодня настолько низкий, что куда уже ниже и зачем — не очень понятно. И так легко все.


  1. Shatun
    00.00.0000 00:00
    +4

    В статье довольно много голословных пунктов по поводу преимуществ mysql без примеров, при этом большинство из них противоречат моему опыту(хотя я не ДБА).

    Из личного опыта:

    • в постгресе гораздо богаче синтаксис и проще писать сложные запросы(в mySQL отсуствуют иногда довольно базовые вещи для базы данных, например -full outer join)

    • оптимизатор в постгресе работает лучше, при переезде многие запросы без индексов стали работать быстрее без каких-либо глобальных изменений в них(те же джоины на некоторых таблицах стали выполняться быстрее без индексов, очень интересно почему)

    • больше актульаных материалов, некоторые проблемы проще гуглятся на постгресе, для mysql нахожу много ответов для версии 5.7(которая прямо уступает соврменному mysql). Также довольного много соврменных книг, статей по внутрянке PostgreSQL.

    Из своего опыта не вижу ситуации когда я бы предпочел MySQL для нового проекта .


  1. velipre_xella
    00.00.0000 00:00

    PG в РФ сейчас это в том числе и кровавый интерпрайз, а МусКул - это ламповое до сих пор.


  1. anone2918932
    00.00.0000 00:00
    +1

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

    К примеру- postgresql медленнее. Насколько? Если на 10% есть ли смысл? Если скорость повысится масштабированием, есть ли смысл?

    Единственное, что знаю- в постгресе есть встроенный формат для работы с json, иногда это удобнее (хотя и не критически). Так же знаю что есть разница в работе с широтой долготой, не помню в какой-то из баз есть поддержка. Но опять же, это не критический фактор.

    Перефразируя- если это не какой-то проект с миллиардами записей, которых меньше 1%, а обычный энтерпрайз, то есть ли разница? За 9 лет опыта пока что не увидел проектов, что однозначно можно было сказать, вот тут постгрес лучше, а вот тут мускул.

    Или нужно сильно, прямо очень сильно поднять экспертизу конкретно и в мускуле, и в постгресе, по сути стать архитектором бд, что бы явно видеть разницу?


    1. santjagocorkez
      00.00.0000 00:00

      Когда случится переезд в PGSQL (не если, а когда), будет очень больно переносить хотя бы даже схему:

      Возьмём, к примеру, обычные целочисленные типы. Что вообще значит аргумент M у целочисленного типа? Впрочем, в родительской СУБД это объяснение есть. И что хочу сказать: является очень хорошим подспорьем для пользователей забить вообще на оптимизацию в плане storage. Зачем думать, надо ли SMALLINT вместо INT, если можно просто INT(2), ведь да?

      Но дело даже не в этом.

      create table a (a bigint not null);

      Казалось бы, легко и непринуждённо переносится дампом в постгрес (и да, есть вполне годная техника на mysqldump, позволяющая импортировать данные методом COPY, что в постгресе сильно ускоряет процесс миграции). А вот и нет:

      $ mysqldump --compat=postgresql test
      CREATE TABLE "a" (
        "a" bigint(20) NOT NULL
      );
      $

      Откуда там этот M взялся? Он несовместим с PostgreSQL. Он и с ANSI несовместим. Вот и всё. Все целочисленные типы (и, наверняка, не только они) представят шанс повеселиться конкретно в этом месте.

      Отдельно хочется напомнить про обилие режимов работы. Вот только, боюсь, если включить сразу какой-нибудь не нативный режим совместимости, то и смысл в этой, с позволения сказать, СУБД пропадает. Кстати, @MaxRokatansky что там насчёт недостатка постгреса по части "сложности настройки"? Как насчёт включить в рассматриваемую сложность не только my.cnf vs. postgresql.conf, но и присыпать это всё рантайм-конфигами, причём, с учётом того, как эти рантайм-конфиги сказываются в целом на последующем поведении (например, у mysql-подобных некоторые рантайм-конфиги влияют на DDL, что, в свою очередь делает такую настройку независимой от текущих параметров сессии)?

      Впрочем, не всё так радужно и в PostgreSQL.

      Например, CREATE ... IF NOT EXISTS совсем не обязательно не упадёт. Более того, разработчики знают об этом, но, поскольку там у руля Том Лейн, совершенно не считают необходимым поправить хотя бы документацию. Рекомендуемый способ лечения -- ADVISORY LOCKS (WAT?)

      Или, например, Эррера так и не смог заставить партиционированные индексы следовать за своими таблицами-партициями в тот же самый tablespace. Воз и ныне там, лет 7 уже прошло, если не ошибаюсь. Эррера пытался аргументировать, мол, ребяты, надо лечить. Но ему быстро насовали полное лукошко, после чего, я так понимаю, он просто сдался.

      Или, например, ON CONFLICT (arbiter) для партиционированных таблиц работает крайне странно. К примеру, список таблиц определяется еще на этапе планирования, было бы неплохо заглянуть в эти таблицы и поискать арбитр там, но... поскольку у руля Том Лейн, мы будем сыпать сообщениями вида

      begin;
      create table b(a int, b int) partition by list (a);
      create table b_1 partition of b for values in (0);
      alter table b_1 add constraint b_1_pk primary key (a);
      create table b_2 partition of b for values in (1);
      alter table b_2 add constraint b_2_pk primary key (a);
      insert into b(a, b) values (1, 1);
      insert into b(a, b) values (1, 3) on conflict (a) do nothing ;

      -- [42P10] ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification

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


    1. edo1h
      00.00.0000 00:00

      К примеру- postgresql медленнее. Насколько? Если на 10% есть ли смысл?

      ИМХО попытка оценить разницу производительности в процентах не имеет особого смысла. Вернее может быть и имеет, но для каких-то конкретных операций, а не для СУБД в целом.


  1. JuriM
    00.00.0000 00:00
    +6

    "Postgresql поддерживает мульти-мастер репликацию" - в каком месте, интересно?

    "Mysql поддерживает в основном master-slave" А как же Galera кластер?


    1. YuriyAkimov
      00.00.0000 00:00
      -1

      Плюсую. У mysql group replication очень производительный multi-master из коробки в community-версии. Pgsql таким похвастаться не может. MM у pgsql из коробки только в enterprise. Остальные решения - это костыли от сообщества. (Galera, впрочем, тоже)


  1. ruraspb
    00.00.0000 00:00

    Не знаю что тут сказать. Но в многопоточных приложениях postgresql лупит всё известные мне БД в одни ворота. В сорок потоков с интервалом между одной записью в в сорок таблиц со средним объектом в 20 кило jsonb с двумя индексами на таблицу. И держать время записи в 7 миллисекунды. Плюс репликация на слейве десяти таблиц с историей под полмиллиона записей с нуля за десять секунд это нечто.


  1. Fafhrd
    00.00.0000 00:00

    В отличие от этого, опции по управлению транзакциями в MySQL более ограничены.

    Там нет управления уровнями изоляции транзакций, атомарных операций и сейвпоинтов?


  1. DX28
    00.00.0000 00:00

    Думаю наиболее интересный пример сравнения/миграции между этими СУБД это Uber. На хабре есть описание.


  1. firehacker
    00.00.0000 00:00

    Когда-то лет 11 назад довелось писать библиотеку-расширение для MySQL: когда я изучил интерфейс взаимодействия между расширениями и самой СУБД, я был подвален и разочарован — он создал ощущение на коленке придуманной внутренней архитектуры. Возможно это только интерфейс взаимодействия так одебилен в угоду плагинописателям, тогда это одно, но если и для своих внутренних нужд СУБД использует такие poor-designed структуры и способы представления даных, то это грустно.