Postgres vs. SQL Server

0

Nie mogę znaleźć żadnego rzetelnego zestawienia tych dwóch baz

Czy ktoś może ma jakieś większe doświadczenie w pracy z nimi i chciałby się pochwalić?

2

A o co pytasz? Czego potrzebujesz i do jakich celów

3

Podstawowa różnica - Postgres jest w pełni darmowy, za M$ trzeba płacić. Jest wersja darmowa, ale posiada ona wiele ograniczeń, a pełna to już są koszty idące w tysiące (nieraz grube dziesiątki tysięcy PLN). Poza tym są jeszcze inne kwestie licencyjne: zasadniczo Postgres daje Ci wszystko co ma, a na M$ masz licencjonowanie albo per core servera, albo na ilość użytkowników, którzy mogą się z bazą łączyć.

Do niedawna M$ wymagał Windowsa, na którym SQL miał chodzić, a Postgres mógł być zainstalowany zarówno na Linuksie, jak i Windowsie (a być może jeszcze na innych platformach, nie pamiętam i nie chce mi się teraz sprawdzać).

Podobno M$ lepiej sobie radzi z klastrowaniem i skalowaniem, aczkolwiek znam to jedynie z opowiadań. I na część z nich (te, które tutaj podważały Postgresa) była odpowiedź, że to nieprawda, a problemy z Postgresem wynikały z błędów lub niskiej wiedzy administratorów bazy. Ponownie - nie mam w tym doświadczenia, jedynie przytaczam opinie, z którymi się spotkałem. Jest też różnica w zakresie duplikowania - o ile się nie mylę, Postgres oferuje jedynie wariacje na temat replikacji master-slave, natomiast Microsoft ma to bardziej rozbudowane.

Wydajnościowo są porównywalne, ale tutaj tak naprawdę wszystko zależy od tego, jak baza zostanie zaprojektowana i przemyślana.

Do poczytania:
https://www.mssqltips.com/sqlservertip/5745/compare-sql-server-mysql-and-postgresql-features/
https://tableplus.com/blog/2018/10/postgresql-vs-sql-server-database-comparison.html
https://www.brentozar.com/archive/2018/08/two-important-differences-between-sql-server-and-postgresql/
https://www.educba.com/sql-server-vs-postgresql/
https://db-engines.com/en/system/Microsoft+SQL+Server%3BPostgreSQL

2

@cerrato: podał wyłącznie względy ekonomiczne natomiast różnic jest sporo. W pracy korzystam z obu tych baz z obu jestem zadowolony w obu są mniejsze lub większe "mindfucki". Największa różnica jest taka, że w postgresql nie ma procedur. Dużo różnic jest między T-SQL i PL/pgSQL. Inaczej się zarządza MSSQL inaczej PostgreSQL. Inny jest sposób przechowywania danych, inna jest optymalizacja zapytań. Jeśli będziesz chciał jakiś kod na systemie wykonać z poziomu bazy to w postgresql użyjesz np pythona, perla, nawet C natomiast w MSSQL masz C#. Zadaj konkretne pytanie to spróbujemy Ci konkretnie odpowiedzieć bo opisanie wszystkich różnic jest raczej niewykonalne

4

@woolfik: teraz pytam nie żeby się kłócić, ale żeby się czegoś nauczyć.

Powiedz proszę, co miałeś na myśli pisząc, że największa różnica jest taka, że w postgresql nie ma procedur i jak to się ma do tego: https://www.tutorialspoint.com/postgresql/postgresql_functions.htm, https://www.javatpoint.com/postgresql-functions, https://www.postgresql.org/docs/9.1/server-programming.html czy https://www.postgresql.org/docs/9.1/sql-createfunction.html?
Jakie funkcje miałeś na myśli?

projektach wysokiego ryzyka, jak potrzebujesz wsparcia ze strony dostawcy, to za Postgresa też będziesz musiał zapłacić. Czasem może się okazać, że te kilkanaście tysięcy to wcale nie tak dużo

OK, ale z drugiej strony w niewielkich i średnich projektach raczej takie dopieszczanie wymagające wsparcia zewnętrznego albo WTF, którego rozwiązania nie znajdziesz w necie, nie powinien się pojawić, a przy wielkich przedsięwzięciach, których budżety idą w miliony, zatrudnisz fachowców, którzy prawdopodobnie wiedzą przebijają ludzi pracujących na słuchawce u producenta bazy.

2
cerrato napisał(a):

OK, ale z drugiej strony w niewielkich i średnich projektach raczej takie dopieszczanie wymagające wsparcia zewnętrznego albo WTF, którego rozwiązania nie znajdziesz w necie, nie powinien się pojawić, a przy wielkich przedsięwzięciach, których budżety idą w miliony, zatrudnisz fachowców, którzy prawdopodobnie wiedzą przebijają ludzi pracujących na słuchawce u producenta bazy.

I tak i nie. Jeśli chodzi o małe projekty to oczywiście nie ma to większego znaczenia, tu bym patrzył na kompetencje w firmie. Jak masz ludzi od Sql Server, to jak im dasz Postgresa, to coś zepsują. Admini jak i programiści. Zdarzyło mi się pracować w dużych projektach (głównie opartych na Oracle), że serwis ratował sytuację. Oni zawsze mają większą wiedzę (popartą podobnymi przypadkami z całego świata) i dostęp do informacji niż największy magik - ale nie mówimy tu o ludziach na słuchawce.

5

PostgreSQL ma dużo więcej typów danych. Jaki sobie tylko zamarzysz. Chcesz JSON-a - masz, chcesz interval - masz, chcesz point - masz, chcesz XML - masz, chesz każdy z tych typów jako tablica - masz...

5

Mając do wyboru postgresa i sql server, wybrałbym postgresa. Bardzo szybko się rozwija i funkcjonalności, których nie było rok czy dwa temu, już są.
W zasadzie jedyne czego mi brakuje, to Oraclowe LOG ERRORS / EXCEPTIONS INTO.

To co może budzić wątpliwości, to:

  • instrumentacja tego co robi aktualnie baza
  • wsparcie techniczne
  • wsparcie dla różnych "compliance" (SOX, PCI, HIPAA etc.) - nie każdy potrzebuje, nie każdy wymaga, dla niektórych rozwiązań jest więcej/mniej dokumentacji dotyczących
2

Mając do wyboru MSSQL a Postgres wzięła bym Postgres. Niestety byłam zmuszona ostatnio pracować na MSSQL i powiem szczerze w projekcie dziwne rzeczy wychodziły po zabawach między API a LINQ. Do tego stopnia że pewnego pieknego dnia okazało się, że dane od jednego z użytkowników są insertowane na test zamiast na prod. Nigdy wcześniej nie zdarzyła mi się taka maniana w żadnej innej bazie z API postawionym w tym samym systemie.

0

@Tomek Pycia:

A o co pytasz? Czego potrzebujesz i do jakich celów

@woolfik

Zadaj konkretne pytanie to spróbujemy Ci konkretnie odpowiedzieć bo opisanie wszystkich różnic jest raczej niewykonalne

Pośrednio na to odpowiem

Korzystałem z obu z tych baz i nie przypominam sobie abym miał z nimi jakiekolwiek problemy, chociaż uważam że SSMS >>>>> PGAdmin,
ale z jakiegoś powodu często czytając jakieś porównania / lub doświadczenie z postgresem vs inne bazy, to wydawałoby się, że pg jest lata przed konkurencją i zastanawiałem się z czego to wynika

Ja osobiście nie korzystałem z żadnych nietypowych featuresów konkretnej bazy, ani żadnych ogromnych workloadów nie miałem, więc trudno mi było sensownie na to patrzeć z perspektywy swojego doświadczenia

1

To ja bym brał to, co znam lepiej jak nie ma problemu z tym, że SS jest płatny.

4

Specem od MS SQL nie jestem, ale o ile mi wiadomo:

  • PostgreSQL jest zdecydowanie bardziej kompatybilne ze standardem SQLa
  • PostgreSQL jest tańszy, a jak trzeba supportu to jest 2ndQuadrant czy CitusDB
  • PostgreSQL ma wiele rozszerzeń, które wspomagają pracę z:
    • danymi geograficznymi (PostGIS)
    • danymi w czasie (TimescaleDB)
    • wyszukiwaniem tekstowym (tsquery, pg_trgm)
    • struktury drzewiaste (ltree)
    • numerami produktów (isn)
    • liczeniem unikatów (hll)
    • KV (hstore)
    • powiadomienia (NOTIFY)
    • etc.
  • PostgreSQL nie ma query hints, jeśli jest potrzeba na coś takiego to jest to uznawane za bug w planerze
  • PostgreSQL jest łatwiej dostępny w wersji hostowanej (Heroku, Google, Amazon, OVH, Citus, etc.)
  • PostgreSQL pozwala na benchmarkowanie swojej DB (IIRC ani MS, ani Oracle, ani IBM na to nie pozwalają)
2
WeiXiao napisał(a):

Pośrednio na to odpowiem

Korzystałem z obu z tych baz i nie przypominam sobie abym miał z nimi jakiekolwiek problemy, chociaż uważam że SSMS >>>>> PGAdmin,
ale z jakiegoś powodu często czytając jakieś porównania / lub doświadczenie z postgresem vs inne bazy, to wydawałoby się, że pg jest lata przed konkurencją i zastanawiałem się z czego to wynika

Ja osobiście nie korzystałem z żadnych nietypowych featuresów konkretnej bazy, ani żadnych ogromnych workloadów nie miałem, więc trudno mi było sensownie na to patrzeć z perspektywy swojego doświadczenia

Pytanie jest od tyłka strony, bo wpierw powinieneś powiedzieć: **do czego chcesz tego użyć? **

Podaj:

  • use case
  • jak ważna jest integralność danych
  • jak duży wolumen danych będzie obsługiwany (spodziewany w najgorszym przypadku)
  • jak dużo funkcjonalności "spadnie" na bazę danych, czy tylko będzie sobie te dane radośnie przechowywać i zwracać, czy np. powinna ona ważną częścią logiki aplikacji z punktu widzenia poprawności danych (przykład: aplikacja nie będzie za "mocno" weryfikować danych, za to baza już to będzie robić)
  • jak ważna jest szybkość zapisu
  • jak ważna jest szybkość odczytu
  • jaki ma być generalnie "ruch" do bazy, ile zapytań, czy to będzie się zmieniać
  • jak ważna jest skalowalność, czyli:
    a) czy baza będzie siedzieć na jednej i tylko jednej instancji i koniec
    b) powinna potrafić się wyskalować (jakoś) w sytuacji awaryjnej
    c) musi się dobrze skalować od samego początku
  • jaki stack będzie współpracował z bazą (tu ważna może być dostępność sterowników i libów do danego stacku)
  • z punktu widzenia administracji, czy to ma być kij w tyłku administratora, czy coś maksymalnie prostego, bo np. dział DevOps nie chce się żreć
  • czy ma być płatny support ze stosownym papierkiem i gwarancjami czy nie
  • jaki jest budżet

Tak z 100 innych powodów jest jeszcze, ale nie pamiętam.

0

jak ważna jest integralność danych

bardzo ważna

jak dużo funkcjonalności "spadnie" na bazę danych, czy tylko będzie sobie te dane radośnie przechowywać i zwracać, czy np. powinna ona ważną częścią logiki aplikacji z punktu widzenia poprawności danych (przykład: aplikacja nie będzie za "mocno" weryfikować danych, za to baza już to będzie robić)

raczej baza tylko przechowuje, więc brak cudów po stronie bazy

jak ważna jest szybkość zapisu
jak ważna jest szybkość odczytu

wysoka szybkość odczytu jest o wiele ważniejsza niż zapisu

jak ważna jest skalowalność, czyli:

Raczej 1 instancja

jaki stack będzie współpracował z bazą (tu ważna może być dostępność sterowników i libów do danego stacku)

W obu przypadkach jest OK

z punktu widzenia administracji, czy to ma być kij w tyłku administratora, czy coś maksymalnie prostego, bo np. dział DevOps nie chce się żreć

fajnie gdyby "wszystko" co trzeba było out of the box i nie trzeba było się z tym męczyć lub co tydzień coś robić

jaki jest budżet

Raczej taki jak ceny tych baz w cennikach przykładowych hostingów

screenshot-20200609185959.png

screenshot-20200609185949.png

Ewentualnie zabawa w konkretny dedyk/vps i postawienie na nim bazy

jaki ma być generalnie "ruch" do bazy, ile zapytań, czy to będzie się zmieniać

strzelam: 10 queries / sec w dzień, 0.x w nocy

1

Problem MSSQL jest licencjonowanie. Jeżeli aplikacja będzie udostępniała dane na świat (np. użytkownik anonimowy via Internet) to trzeba zakupić coś takiego jak External Conector , a ztego co wiem to kosztuje ponad $2000.

[(https://www.microsoft.com/pl-pl/licensing/product-licensing/client-access-license)]

0

@WeiXiao: bazując na tym co napisałeś, użyj tą, którą lepiej znasz/łatwiej Ci użyć. Jeśli koszt nie jest żadnym problemem (nie znam niuansów MS SQL tutaj), to możesz nawet poszukać firm, które Ci któryś z tych silników postawią, skonfigują i będą supportować, by mieć problem "z głowy". Jeżeli aż takich funduszy nie masz, to rozważ PG/MSSQL w którymś cloudzie, którego sobie wyklikasz zwyczajnie, powinno być tańsze (do pewnego momentu wielkości bazy i/lub ruchu na niej.)

3

Obie bazy mają podobne możliwości, a różnią się głównie bardziej egzotycznymi ficzerami. SS jest jak windows, bardziej idioto odporny, więcej rzeczy jest zautomatyzowanych, przyjaźniejszy w obyciu i łatwiejszy w administrowaniu. Postgres jest jak linuks, wymaga większej wiedzy, łatwiej jest coś zepsuć, i zamiast wykilkiwać coś w ui trzeba edytować configi albo pisać skrypty.

Ja jestem leniwy i wygodny, więc jeśli projekt stać na licencję sql servera to go zawsze wybieram, w przeciwnym razie pozostaje darmowy postgres.

z podstawowych różnic :

  • postgres nie ma indeksów klastrowanych, można co jakiś czas samemu klastrować tabelę
  • widoki zmaterializowane w postgresie się same nie odświeżają
  • automatyczne usuwanie starych wierszy w postgres (auto vacuum) bywa problematyczne
  • w sql serverze mamy trzy modele współbieżności do wyboru: najstarszy oparty na blokadach (czytelnicy blokują pisarzy), nowszy oparty na wersjonowaniu wierszy (czytelnicy nie blokują pisarzy), i najnowszy, optymistyczny, dla tabel zoptymalizowanych w pamięci (nikt nie blokuje nikogo), natomiast w postgesie mamy tylko wersjonowanie wierszy MVCC
  • współbieżne plany zapytań dopiero niedawno zostały dodane do postgressa i są daleko w tyle za sql serverem pod względem możliwości
  • nowsze wersje sql servera zmierzają w kierunku samo tuningowania dzięki Query Store, potrafi baza wykryć i zareagować jeśli plan zapytań nie wykonuje się tak dobrze jak kiedyś, zostały dodane operatory hybrydowe które mogą się zmieniać w trakcie wykonania planu jeśli okaże się w trakcie odczytu danych że statystki kłamały, a w postgressie całe tuningowanie trzeba wykonać samemu
  • wyrażenia CTE w sql serwerze mają mniejsze możliwości niż w postgressie i nie są zgodne ze standardem i czasem mogą zaskoczyć rezultatem ;)
7

Zawodowo zajmuje się tylko SQLServerem, Postgres z czystej ciekawości śledzę, nie znam postgressa na tyle, aby pokusić się na porównania i nie znam osoby, która byłaby na tyle biegła w duecie postgress+sql server, szybciej duet oracle+sql server.

W ramach pogłębiania wiedzy o, odniosę się do postu @hauleth:

  • PostgreSQL jest zdecydowanie bardziej kompatybilne ze standardem SQLa

tsql ma swoje własne rozszerzenia niezgodne ze standarem, ale IMO żaden silnik nie jest w 100% kompatybilny ze standardem i jakoś po 20 latach z SQL Serverem nie przypominam sobie sytuacji, żeby ten brak kompatybilności mi coś utrudnił

  • PostgreSQL jest tańszy, a jak trzeba supportu to jest 2ndQuadrant czy CitusDB

Tu zgoda, tylko cena nie jest miarą mozliwości technicznych silnika, dla mnie argument trochę na siłe, nawet jeśli licencja SQLServera byłaby za 1$ to i tak "przegrywa" z Postgresem

  • PostgreSQL ma wiele rozszerzeń, które wspomagają pracę z:
    • danymi geograficznymi (PostGIS)

SQL Server może przechowywać dane geograficzne i geometryczne spatial data

  • danymi w czasie (TimescaleDB)

timescaldb to osobny produkt i to nie bardzo mi pasuje do porównywania silników

  • wyszukiwaniem tekstowym (tsquery, pg_trgm)

Tu brakuje mi wiedzy z postgresa, ale wszystkie linki nawiązują do full-text search w SQL Server

  • struktury drzewiaste (ltree)

w sql server hierarchyid

  • numerami produktów (isn)

out of box nie ma

liczeniem unikatów (hll)

To jest rozszerzenie do postgresa, ale masz również implementacje HyperLogLog dla SQL Server: https://github.com/shuvava/mssql-hll, za to out of box masz: APPROX_COUNT_DISTINCT

  • KV (hstore)

SQL Server nie ma

  • powiadomienia (NOTIFY)

Jest Service Broker

  • PostgreSQL nie ma query hints, jeśli jest potrzeba na coś takiego to jest to uznawane za bug w planerze

niekoniecznie, czasami chce odczytać dane zanim skończy się jakaś transakcja, więc nie muszę czekać na jej zakończenie tylku użyć hintu nolock, ja uważam hinty za przydatne, mam możliwość jawnie poinformować silnik czego oczekuje

  • PstgreSQL jest łatwiej dostępny w wersji hostowanej (Heroku, Google, Amazon, OVH, Citus, etc.)

Tu się zgodzę, bo np. wersja Azure SQL nie ma wszystkich możliwości pełnego SQL-a

  • PostgreSQL pozwala na benchmarkowanie swojej DB (IIRC ani MS, ani Oracle, ani IBM na to nie pozwalają)

Nie wiem jaki ma to związek z możliwościami, ale faktycznie licencja na to nie pozwala

1

timescaldb to osobny produkt

TimescaleDB to rozszerzenie PostgreSQLa, więc jak najbardziej pasuje.

czasami chce odczytać dane zanim skończy się jakaś transakcja, więc nie muszę czekać na jej zakończenie tylku użyć hintu nolock

W Postgresie używany jest wyłącznie MVCC, który (prawie) zawsze pozwala na odczyt danych. Więc o ile wcześniej sam nie nałożysz blokady, to ten problem nie istnieje.

0

TimescaleDB to rozszerzenie PostgreSQLa, więc jak najbardziej pasuje.

to czemu tu się porównuje timescale z postgresem?

https://db-engines.com/en/system/Microsoft+SQL+Server%3BPostgreSQL%3BTimescaleDB

W Postgresie używany jest wyłącznie MVCC, który (prawie) zawsze pozwala na odczyt danych. Więc o ile wcześniej sam nie nałożysz blokady, to ten problem nie istnieje.

nolock to był tylko przykład tych hintów jest więcej, hintów praktycznie nie używam, ale nie traktowalbym tego w kategoriach lepsze/gorsze. Bo mozna to obrucić i napisać, że Posgres jest gorszy bo nie pozwala setrować wykonywaniem zapytań, a jestem przekonany, że znaleźlibysmy jakiś case kiedy by to się moglo przydać ;)

2

to czemu tu się porównuje timescale z postgresem?

https://db-engines.com/en/sys[...]er%3BPostgreSQL%3BTimescaleDB

Z tego samego powodu z jakiego można je porównać z Citusem. Czytaj - nie mam zielonego pojęcia, ale pozwól, że zacytuję README TimescaleDB:

It is engineered up from PostgreSQL and packaged as a PostgreSQL extension

Tak samo jest z Citusem:

  • Open-source PostgreSQL extension (not a fork)

nie traktowalbym tego w kategoriach lepsze/gorsze

Też tego tak nie traktuję, ja to wymieniałem raczej jako różnice niż "lepsze/gorsze". Jak na razie tylko raz spotkałem się z przypadkiem gdy jakaś forma hinta miałaby sens - wymuszenie nowego planu dla prepared statements, bo czasem może się okazać, że pierwotne zapytania wygenerowały nienajlepszy plan w ogólnym przypadku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1