Software-update: PostgreSQL 9.5.3 / 9.4.8 / 9.3.13 / 9.2.17 / 9.1.22

Er zijn updates verschenen van PostgreSQL uit de 9.5-, 9.4-, 9.3-, 9.2-, en 9.1-serie. Daarnaast is ook de eerste bètarelease van versie 9.6 uitgebracht. Dit populaire 'opensource relational database management system' draait op een groot aantal besturingssystemen en is daardoor uitstekend inzetbaar in diverse omgevingen. Het is een afgeleide van Ingres, nadat de hoofdontwikkelaar daarvan voor zichzelf is begonnen en deze database van opensource closedsource werd. De release notes voor deze bugfix-uitgave kunnen hieronder worden gevonden.

This update fixes several problems which caused downtime for users, including:

• Clearing the OpenSSL error queue before OpenSSL calls, preventing errors in SSL connections, particularly when using the Python, Ruby or PHP OpenSSL wrappers
• Fixed the "failed to build N-way joins" planner error
• Fixed incorrect handling of equivalence in multilevel nestloop query plans, which could emit rows which didn't match the WHERE clause.
• Prevented two memory leaks with using GIN indexes, including a potential index corruption risk.

The release also includes many other bug fixes for reported issues, many of which affect all supported versions:

• Fix corner-case parser failures occurring when operator_precedence_warning is turned on
• Prevent possible misbehavior of TH, th, and Y,YYY format codes in to_timestamp()
• Correct dumping of VIEWs and RULEs which use ANY (array) in a subselect
• Disallow newlines in ALTER SYSTEM parameter values
• Avoid possible misbehavior after failing to remove a tablespace symlink
• Fix crash in logical decoding on alignment-picky platforms
• Avoid repeated requests for feedback from receiver while shutting down walsender
• Multiple fixes for pg_upgrade
• Support building with Visual Studio 2015

Versienummer	9.5.3 / 9.4.8 / 9.3.13 / 9.2.1
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, macOS, Windows Vista, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10
Website	PostgreSQL
Download	http://www.postgresql.org/downloads
Licentietype	Voorwaarden (GNU/BSD/etc.)

Update-historie

• 18-08 PostgreSQL 9.6.4 / 9.5.8 / 9.4.13 / 9.3.18 / 9.2.22
• 09-'16 PostgreSQL 9.6
• 08-'16 PostgreSQL 9.5.4 / 9.4.9 / 9.3.14 / 9.2.18 / 9.1.23
• 05-'16 PostgreSQL 9.5.3 / 9.4.8 / 9.3.13 / 9.2.17 / 9.1.22
• 01-'16 PostgreSQL 9.5
• 05-'15 PostgreSQL 9.4.2 / 9.3.7 / 9.2.11 / 9.1.16 / 9.0.20

• 02-'15 PostgreSQL 9.4.1 / 9.3.6 / 9.2.10 / 9.1.15 / 9.0.19
• 12-'14 PostgreSQL 9.4
• 03-'14 PostgreSQL 9.3.4 / 9.2.8 / 9.1.13 / 9.0.17 / 8.4.21
• 10-'13 PostgreSQL 9.3.1 / 9.2.5 / 9.1.10 / 9.0.14 / 8.4.18

Meer historie

Reacties (55)

Ondanks dat het nooit de populariteit van MySQL gehad heeft, is PostgreSQL gewoon een veel betere database, die zowat Oracle naar de kroon kan steken.

Zou je dit kunnen toelichten? Zelf nog niet met PostgreSQL gewerkt.

Dat is een heel breed onderwerp, want PostgreSQL kan op veel punten meer dan MySQL. Wat voor mij echter een rol speelt is het gebruik bij het goed ontwerpen van software.

Stel, je bent een webpagina aan het schrijven waar de database voor nodig is. Bijvoorbeeld zoals hier een forum met reacties. Je hebt een query nodig om alle reacties uit de database te halen, maar je hebt voor iedere reactie ook nog gegevens nodig, bijvoorbeeld de gebruikersgegevens om de juiste naam erbij te zetten.

Idealiter join je een paar tabellen aan elkaar en haal je alles in één keer op. Waar je bij MySQL echter vrij snel tegenaan loopt, is dat je in minder triviale situaties het niet meer met een enkele query kunt oplossen: Je bent gedwongen voor iedere rij die je terugkrijgt een nieuwe query te starten. Een dergelijke aanpak maakt je ontwerp stukken minder efficiënt en het leidt vaak tot overbelaste databaseservers.

Bij PostgreSQL loopt je veel minder snel tegen een muur op dat je het niet meer op een nette manier kunt doen: Je hebt veel meer functies, je kunt eigen functies schrijven, je kunt views gebaseerd op functies maken, en teveel om op te noemen.

Ook wat betreft het aanleggen van indexen is PostgreSQL veel flexibeler, zodat je veel meer gereedschappen hebt om prestatieproblemen op het niveau van de database te lijft te gaan i.p.v. dat je tegen een muur oploopt en lelijke softwarehacks moet gaan uithalen om de boel te optimaliseren.

Maar dit is één aspect: Er zijn er velen. Traditioneel was de achilleshiel altijd de ACID-conformiteit van MySQL. Dat is nu beter, nog altijd is de database met de olifant de betere. En wat procedure talen betreft... ik weet niet eens of MySQL ze überhaupt wel heeft.

Bij PostgreSQL loopt je veel minder snel tegen een muur op dat je het niet meer op een nette manier kunt doen: Je hebt veel meer functies, je kunt eigen functies schrijven, je kunt views gebaseerd op functies maken, en teveel om op te noemen.

Je hebt in MySQL al een aardig tijdje stored procedures, functions en views - wat ontbreekt daar volgens jou dan aan?

Nou, zoals ik zei, ik wist niet eens of MySQL ze inmiddels had. Dat is dus een ja. Maar... laten we de documentatie er eens op naslaan, we vergelijken de MySQL stored procedure met Pl/PgSQL, één van de talen (er zijn er een aantal) waarin je in PostgreSQL procedures en functies kunt schijven:

http://dev.mysql.com/doc/refman/5.7/en/create-procedure.html
http://www.postgresql.org/docs/8.3/static/plpgsql.html

... je ziet in een oogopslag dat het een wereld van verschil is.

Je moet ze maar net willen gebruiken natuurlijk, persoonlijk wil ik alle business logic in de applicatie hebben en niet in de database, debuggen is echt een hel met stored procedures. Wat meer queries doen is niet per definitie slecht als je daarmee je applicatie beter onderhoudbaar maakt, zeker als je database makkelijk schaalbaar is door replicatie e.d. hoeft dat geen breekpunt te zijn.

Triggers net zo, ik heb er een hekel aan, ik wil dat soort gedrag in het model van mijn applicatie hebben, zeker als je dat allemaal geautomatiseerd wil gaan testen wordt dat een stuk minder complex.

Portabiliteit is een ander punt, met een goede ORM die generieke queries doet kan je zo van database switchen, probeer dat maar eens als de helft van de logica met DBMS specifieke dingen geschreven zijn...

Voordat MySQL foreign key ondersteuning kreeg moest iedereen dit ook in de applicatie afhandelen. Zou je dat nu nog doen?

Triggers, stored procedures en check constraints zijn allemaal net zo onmisbaar als de unique, foreign key, not null constraints, ze hebben alleen een ander doel.

Als je echt puur alle logica in de applicatie wil hebben, dan zou je ook zelf moeten kijken of waardes uniek zijn, not null, dat de foreign keys kloppen etc. Dat doe je ook niet. Net zo goed als je voor bepaalde situaties wel triggers, checks en stored procedures gebruikt (bijvoorbeeld partitioned tables)

Al helemaal wanneer je database je primaire applicatie is (zoals in mijn geval) en de applicatie alleen een presentatie tool van complexe query's.

[Reactie gewijzigd door CurlyMo op 16 mei 2016 13:01]

Een van de zaken die echt een heel erstig gemis zijn in mysql is dat je in triggers geen andere triggers mag af laten gaan, en geen procedures op andere tables kan callen.
Daardoor is het maken van ehte buisiness logica in mysql zogoed als onmogelijk.
In Postgres kan dat allemaal gewoon wel.

Zodra je serieus met databases aan de slag gaat, dan zul je dat vanzelf wel merken. Dingen waar ik niet zonder kan:
- DISTINCT ON (ook niet aanwezig in Oracle en MSSQL)
- Window functies
- Schemas
- Postgis (unieke module voor PostgreSQL)
- Custom data types
- Deferred FKEY en triggers
- Indexes op expressies

Ook leuk:
- Python as procedural language

En zo kunnen we wel even doorgaan Dat is precies wat @dmantione hier ook beschrijft. PostgreSQL is immens uitgebreid en vrijwel alles wat je je kan bedenken wordt in PostgreSQL ondersteund. Verder is een belangrijke performance. Daar waar wij zowel Oracle als PostgreSQL gebruiken, is de laatste vele malen sneller is onze workflow.

Wat wel een groot gemis is in PostgreSQL is het gebrek aan een incremental materialized view.

[Reactie gewijzigd door CurlyMo op 15 mei 2016 10:49]

En iets wat niet veel mensen weten omdat bijna niemand het gebruikt, er is tegenwoordig een partij die het mogelijk maakt om in postgres chemische queries te draaien. Dat wil zeggen dat je bijvoorbeeld substructure searches kan doen, direct in de database.
Ter vergelijking: een substructure search in mysql op 12 miljoen compounds (haalt alle compounds op en doet een voor een de matchpoging): 40 minuten.
De zelfde substructure search in postgres op 12 miljoen compounds (gebruikt chemindex): 35 seconden.
Dit is overigens niet gratis, maar niet belachelijk duur zoals bijvoorbeeld een oracle database, die vergelijkbare performance levert.

Postgres bescherm je data, MySQL niet.

Zie de volgende video: https://www.youtube.com/watch?v=1PoFIohBSM4 en huiver.
MySQL past bij vele programmeursfouten de gegevens in de database aan. Teksten afkappen, valuta inkorten, 31-februari opslaan als 00-00-0000? Geen enkel probleem.

[Reactie gewijzigd door YaPP op 15 mei 2016 15:26]

Daar hebben ze bij mysql strict mode voor hoor. Als je een degelijke database driver gebruikt wordt deze standaard aangezet

Dit soort discussies zijn meestal gebaseerd op persoonlijke ervaring en gebrek daaraan bij de concurrerende software. Er zijn heus wel dingen die postgres beter doet dan mysql, maar andersom ook.
Probeer maar eens een simpele master-master replicatie op te zetten met postgres. Bij mysql super simpel, bij postgres totaal niet. Dan moet je aan de slag met 3rd party tools. Een goeie redundant setup met postgres is redelijk lastig. Bij een master-slave moet je handmatig de master recoveren na downtime.

Licentietechnisch is PostgreSQL beter bij je software te bundelen. PostgreSQL heeft al jaren een trouwe hoeveelheid developers, welke ieder jaar ook weer groeit.

Om een vergelijking aan te geven, een open source event waar ik ieder jaar heen gaat heeft MySQL altijd een redelijk grote zaal, deze lijkt ieder jaar een stuk leger te worden, jaren geleden zat deze prop vol.
De kleinere PostgreSQL zaal puilt vaak uit van de mensen. En dat terwijl ze toch iedere keer een grotere zaal nemen.

Verder vind ik het stricte wel fijn. MySQL doet dat ook steeds beter. Maar de ervaring leert dat veel developers dit toch weer uit zetten.

Ook de tooling om PostgreSQL heen is best goed. Barman vind ik gewoon een van de mooiste Backup / Recovery oplossingen die er is. Voor MySQL heb ik nog niet echt iets gevonden die die kant op gaat.

Mijn voorkeur is om een database server bovenop een FreeBSD ZFS te bouwen zoals hier uitgelegd (vanuit OpenIndiana). Door het gebruik van ZFS heb je de mogelijkheid om immens snel incremental snapshots te maken van je data en ook alleen de incrementals te backuppen naar een externe locatie. Wanneer nodig kan je je database readonly benaderen vanuit je snapshot, of door je snapshot te clonen heb je weer een read/write situatie van je data van dat moment.

Dat ziet er ook goed uit ja!
Laat me dat ook maar eens belijken

Wat dreambofh zegt: De licentie van PostgreSQL is veel beter dan de MySQL licentie.

PostgreSQL gebruikt de PostgreSQL licentie vergelijkbaar met BSD/MIT. Dit betekent dat je er alles mee mag doen, inclusief distribueren:

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted

MySQL daarentegen is GPL (blauwe blokje rechts boven), wat betekent dat je MySQL wél mag gebruiken maar niet mag distribueren als je eigen applicatie GEEN GPL licentie heeft.

Hier moet je dus heel goed rekening mee houden als je zelf software schrijft en een database mee wilt leveren. MySQL mag je dus NIET meeleveren als je closed-source maakt, tenzij je met MySQL/Oracle een commerciele licentie afsluit (Zie punt Q3):

OEMs, ISVs and VARs that want the benefits of embedding commercial binaries of MySQL software in their commercial applications but do not want to be subject to the GPL and do not want to release the source code for their proprietary applications should purchase a commercial license from Oracle. Purchasing a commercial license means that the GPL does not apply, and a commercial license includes the assurances that distributors typically find in commercial distribution agreements.

wat betekent dat je MySQL wél mag gebruiken maar niet mag distribueren als je eigen applicatie GEEN GPL licentie heeft.

Sorry, dit is echt grotendeels klinkklare onzin; dat geldt echt alleen maar wanneer je libmysql gebruikt. Veel GPL applicaties maken uitzonderingen voor hun libraries, MySQL misschien niet dat geloof ik graag. Echter een SQL server praat SQL, en een SQL client ook. De licentie van de server heeft geen enkele invloed op de licentie van de client. Een HTTPd die GPL is mag ook gewoon praten met een web browser die geen GPL is. WAMP ipv LAMP mag ook gewoon.

[...]
Sorry, dit is echt grotendeels klinkklare onzin; dat geldt echt alleen maar wanneer je libmysql gebruikt. Veel GPL applicaties maken uitzonderingen voor hun libraries, MySQL misschien niet dat geloof ik graag.

En MySQL was nou precies waar we het over hadden. Als je MySQL meelevert met je applicatie, dan moet je daarvoor een commercial license aanschaffen. (http://www.mysql.com/oem/). Dat is toch echt wel duidelijk uit het zinnetje:

OEMs (Original Equipment Manufacturers), ISVs (Independent Software Vendors), VARs (Value Added Resellers) and other distributors that combine and distribute commercially licensed software with MySQL software and do not wish to distribute the source code for the commercially licensed software under version 2 of the GNU General Public License (the "GPL") must enter into a commercial license agreement with Oracle.

Dus hier boven staat: als je MySQL software wilt meeleveren/embedden, dan moet je óf een open source project zijn mét GPL licentie, óf een commerciële MySQL licentie kopen. (Bron, tweede alinea)

Echter een SQL server praat SQL, en een SQL client ook. De licentie van de server heeft geen enkele invloed op de licentie van de client. Een HTTPd die GPL is mag ook gewoon praten met een web browser die geen GPL is. WAMP ipv LAMP mag ook gewoon.

Dat MySQL SQL praat is fijn, maar dat staat hier niet ter discussie. Het onderwerp hier is of de licentie het toestaat dat je het wel of niet (gratis) mag meeleveren met je eigen open source/commerciële applicatie. Apache, MySQL, PHP zijn alle drie open source projecten, zij het met ieder een eigen licentievorm (Apache: Apache License, Version 2.0 vs MySQL: GPL2 vs PHP: BSD).

Hoef ik allemaal niet te lezen want ik weet hoe dat werkt. Dat telt alleen als jij naar de libraries linkt (wat jij noemt meeleveren, maar dat is veel minder accuraat!!!). Praat jouw applicatie SQL en verbindt deze met de MySQL server op port 3306 dan hoef jij niets te betalen. Kom niet beweren dat dat nooit gebeurd. Bij een DB server gebeurt dat altijd. Want een DB server praat over netwerk. Zo niet moet je je afvragen of de overhead het waard is. Uiteraard kun je ook gewoon voor PostgreSQL gaan dan heb je al dit gezaag niet.

Hoef ik allemaal niet te lezen want ik weet hoe dat werkt.

Misschien dat je dan ook mijn argumenten had gelezen. "Distribute" staat er toch echt.

Dat telt alleen als jij naar de libraries linkt (wat jij noemt meeleveren, maar dat is veel minder accuraat!!!).

Linken en meeleveren zijn twee verschillende dingen. Ik heb het over het meeverschepen van de MySQL binaries als onderdeel van de installatiepackage van de eigen applicatie die commercieel verkoop. Niet over het verbinden met een MySQL server. Dat laatste heb ik nooit genoemd als argument, dat haal jij er bij.

Praat jouw applicatie SQL en verbindt deze met de MySQL server op port 3306 dan hoef jij niets te betalen.

Dat is "verbinden met", en daar heb ik het niet over.

Kom niet beweren dat dat nooit gebeurd. Bij een DB server gebeurt dat altijd. Want een DB server praat over netwerk.

Heb ik dat beweerd? (Off topic: HSQLDB heeft een embedded server die helemaal geen netwerk component gebruikt, dus ook dat argument mag je niet meer gebruiken.)

Je kunt prima MySQL distribueren met jouw applicatie wanneer jouw applicatie met MySQL over het netwerk praat.

Waarom je MySQL mee zou leveren met jouw applicatie is me een raadsel. Je kunt met een package management systeem namelijk ook gewoon het als dependancy opgeven.

Zal wel Docker en embedded markt zijn.

Zolang je de library niet gebruikt is er niets aan het handje. En networking SQL babbelen zal niet veel overhead leveren.

Anyway, jij schreef:

wat betekent dat je MySQL wél mag gebruiken maar niet mag distribueren als je eigen applicatie GEEN GPL licentie heeft.

Ik neem aan dat je nu begrijpt waarom die opmerking niet klopt? Want daar ging het me om.

[Reactie gewijzigd door Jerie op 17 mei 2016 15:09]

[...]
Ik neem aan dat je nu begrijpt waarom die opmerking niet klopt? Want daar ging het me om.

Nee, ik begrijp niet waar je op doelt. De GPL licentie is hier heel duidelijk in: je mag een GPL component alléén distribueren als je eigen applicatie óók GPL is.

Een niet-GPL applicatie mag dus geen MySQL binaries distribueren. MySQL heeft daarin voorzien middels een dual-license strategie: je zult in dit geval een licentieovereenkomst moeten sluiten.

Als jij MySQL installeert om er je WordPress installatie op te draaien, prima, dan distribueer je niks, je gebruikt het.

Feel free to enlighten me.

Hoezo zou je dat niet mogen distribueren? Dat zou betekenen dat je geen Ubuntu ISO mag distribueren. Daar staat immers GPL software, en non-GPL software op goeie grap! Het euvel zit hem meestal bij de libraries. Daar heb je dan vaak exceptions op. Ik geloof je op je blauwe ogen wanneer je zegt dat MySQL die exception niet heeft (ik weet dat niet). Niet iedere library heeft zo'n exception. Dit is wel waarom vaak de LGPL voor libraries wordt gebruikt. Alweer weet ik niet of dat bij MySQL het geval is.

Maar zoals ik al zei maakt het eigenlijk niet uit. Want bij het geval wat ik zeg is de applicatie geen component. Als jij met je browser naar Tweakers.net gaat op port 80 of 443 dan is jouw browser ook niet ineens geen component van Tweakers. Hetzelfde met wanneer je SQL client naar port 3306 gaat om met de SQL server SQL te babbelen. Het feit dat de server dan GPL is maakt de client dan niet GPL (of vice versa).

Waarom haal je nou iedere keer die netwerkcommunicatie er bij? Daar heb ik het helemaal niet over. Ik heb gewaarschuwd voor de commerciële distributie van de database zelf, niet de communicatie met een client o.i.d.

Jij geen GPL op je eigen commerciële applicatie? Dan moet je een MySQL licentie kopen. Korter dan dit kan ik het niet uitleggen.

Dit artikel legt het goed uit:

It is forbidden to develop a commercial product, such as a bookkeeping program, that is geared toward MySQL as the database without making the code available in the open source sense. If the limitations of the GPL are not acceptable to you as a commercial developer, then you may sell your product (program) together with a commercial MySQL license.

Waarom haal je nou iedere keer die netwerkcommunicatie er bij?

Omdat het relevant is. Bijvoorbeeld hier:

It is forbidden to develop a commercial product, such as a bookkeeping program, that is geared toward MySQL as the database without making the code available in the open source sense.

Het is perfect mogelijk om een commercieel product te maken dat gebruik maakt van MySQL als database met daarbij het database gedeelte networked. Daarmee kom je onder de GPL uit.

Je hoeft dan niet eens MySQL met je software te distribueren.

Eigenlijk is de quote een red herring. Het slaat de plank mis omdat het allerlei mogelijkheden negeert.

Stel dat iemand een applicatie host die gebruik maakt van MySQL, is het dan mogelijk om PostgreSQL in de plaats van MySQL te gebruiken zonder aanpassingen aan de applicatie te hoeven maken?

Waarschijnlijk niet. Als je een ORM-systeem gebruikt en nooit custom queries draait moet 't wel lukken mits het ORM-systeem PostgreSQL ondersteund. In die situatie biedt PostgreSQL alleen weinig voordelen. De kracht van PostgreSQL komt juist naar boven bij geavanceerde queries die meer dan alleen ANSI SQL gebruiken. Als je er echt iets aan wilt hebben moet je de queries herschrijven en waar mogelijk combineren en/of herschrijven.

Dat is precies mijn ervaring ook.

MySQL is sowieso dood. De hele opensource wereld is aan het overstappen op de fork MariaDB sinds Oracle het over heeft genomen.

Ik kijk even naar vele versie nummers. 9.1 tot 9.5?
Hoe komt het eigenlijk dat men niet gewoon 9.5 van maakt.
Bij MySQL heb je niet zoveel versies, maar hier vind ik wel heel wat, elke kleine versie eigen fix.

Ze blijven oudere versies ondersteunen, door voor 9.x (9.1 t/m 9.5) nog bug-fixes uit te brengen, die krijgen dan de naam 9.x.y, waarbij y telkens verhoogd wordt. Dit is vooral prettig in productie omgevingen zodat die wel security updates krijgen, maar het niet de applicatie kan breken.

ik snap het

Wist niet dat er aardig wat verschillen zijn, en kun je dus niet zomaar hogere versie nemen (dus niet risicovrij upgraden). Alles moet goed lopen in de productie omgeving.

Zo te zien maken ze gebruik van Semantic Versioning, dat ziet er als volgt uit:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

De update van 9.1.x naar 9.5.x voegt dus features toe, terwijl het wel backwards-compatible blijft. Ze zouden dus naar 9.5 moeten kunnen upgraden, maar als in een productie omgeving nu 9.1 wordt gebruikt, hebben ze die nieuwe features in 9.5 niet nodig en is het dus veiliger om op 9.1 te blijven.

[Reactie gewijzigd door P1nGu1n op 14 mei 2016 21:45]

Dat is precies waarom linux distributies meestal op dezelfde versie blijven hangen. Nieuwe versies breken vaak oude setups (niet van postgres specifiek maar van software in het algemeen).
Bijvoorbeeld Ubuntu 14.04 (LTS) heeft nog 9.3, en zal die ook altijd houden. De recent uitgebrachte nieuwe LTS (16.04) heeft 9.5 en zal dus geen 9.6 krijgen wanneer deze uit komt.

Het is fijn dat een versie ook gewoon updates krijgt. Nieuwe versies hebben meestal andere mogelijkheden wat niet altijd functioneert i.c.m. oudere software systemen.

Wat ik mij afvraag, als iemand die er geen kennis van heeft, als de performance bijna of geheel gelijk aan die van betaalde DBMS is, waarom migreert niet iedereen (langzaam) naar PostgreSQL?
Ik meen mij nog te herinneren dat bv een Oracle licentie zo $50.000,- op jaarbasis is.

Dat gebeurt bij ons dan dus ook. Een belangrijk verschil is natuurlijk de ondersteuning vanuit Oracle. Bij OSS heb je dat meestal niet en waar je dat wel hebt kost dat ook gewoon (flink) geld. Voorbeeld is Red Hat waarbij het OS gratis en open source is en hun verdienmodel de ondersteuning.

Zoals ik eerder aangaf is in mijn workflow de performance veelal beter met PostgreSQL en ik zei ook dat Oracle op sommige punten verder is dan PostgreSQL maar ook andersom.

Omdat er vele commerciële producten in bedrijven draaien op een Oracle database. Een Enterprise vindt de 50k (vaak veel meer) geen probleem.
Bij Oracle producten is de db bijna altijd bijgeleverd (mits je geen maatwerk toevoegt)

Verder is er veel maatwerk geschreven in PL/SQL, wat uitsluitend op een Oracle db werkt. (Ja, er PL/pgsql, ik heb geen ervaring met overzetten en of dat mogelijk is)

Databases zoals SQL Server, Oracle, DB2 en PostgreSQL (databases die ik in meer of mindere mate ken), zijn allemaal snel. Hoe snel, dat ligt vooral aan de gebruikte hardware en de kwaliteit van de code.

Licenties van Oracle zijn gruwelijk complex, je bent alleen al meer dan $50,000.- kwijt aan kosten voor een advocaat om uit te zoeken wat er nu wel en niet in het contract zit... En daarna komen de licentiekosten zelf nog. En oh wee wanneer je een foutje maakt en de licentie overtreedt, dan mag je bij Oracle op het matje komen en nogmaals afrekenen. En dat afrekenen loopt al snel in de miljoenen. Dat is ook precies de reden waarom PostgreSQL populair is, het is gratis (of goedkoop met EnterpriseDB) en voor 9 van de 10 toepassingen biedt het alle functionaliteit die je nodig hebt.

Postgres is een fijne server. Alleen dat pgAdmin heb ik nooit aan kunnen wennen.

De management tools van SQL Server en MySQL werken veel fijner is mijn ervaring.

Toch hoop ik dat Postgres populairder wordt. Licentievoorwaarden zijn beter dan bij MySQL en Postgres is altijd gegarandeerd ACID compliant.

Alleen die tools

Mogelijk ken je deze al:
https://www.adminer.org/

Simpele beheertool middels 1 enkele php pagina.

[Reactie gewijzigd door Phyt_ op 14 mei 2016 22:12]

Voor de duidelijkheid, de afbeelding die getoond wordt is van pgAdmin, een appartement stuk software om postgres databases mee te beheren. Zou hier eigelijk niet moeten staan.

Super. Na jaren met MySQL gewerkt te hebben ben ik in 2009 overgestapt op PostgreSQL. Nooit meer omgekeken.

Oracle is idd prijzig, 50k is niks afhankelijk van het gebruik. Maar wat ik bij Oracle wel zie is dat ze volgens mij op HA gebied veel verder zijn met hun RAC clustering. DB over meerdere sites heen draaien is geen enkel probleem, evenals hot of vold standby. Hoe dat bij PostgreSQL zit weet ik niet helaas (enlighten me via DM aub)

Waar heb je het over?

Ehh.. Nee, Postgres != SQL. Geen idee wat je daarmee bedoelt. De reden voor de update staat gewoon in de post, namelijk het fixen van de genoemde bugs. Ook geen idee wat je met MS bedoelde, maar als dat MySQL is: Er is een lange lijst van dingen die PostgreSQL (al sinds lange tijd) wel kan, en MySQL niet. En wat bedoel je precies met je opmerking of het "nu ineens wél veilig" is?

Ja, je kunt het herhalen met een smiley erachter, maar daarmee is voor mij (en ik gok voor niemand) ook maar iets duidelijker wat je met die vorige reacties nou eigenlijk wilde zeggen...

PostgreSQL = SQL, maar SQL != PostgreSQL

SQL is een querytaal. Postgres is een database. Appel, peer.

ja en alle dieren ter wereld zijn olifanten!

of stel je dit soort reacties ook bij elke bugfix in windows skype en andere meuk die je wel gebruikt.