Software-update: PostgreSQL 15

Versie 15 van PostgreSQL is uitgekomen. 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 Postgres, wat op zijn beurt weer is geïnspireerd op Ingres, nadat de hoofdontwikkelaar daarvan voor zichzelf is begonnen en deze database van opensource closedsource werd. Uitgebreide informatie over de veranderingen in versie 15 kan het deze pagina worden gevonden. De complete changelog staat hier, dit zijn in het kort de belangrijkste verbeteringen:

PostgreSQL 15 contains many new features and enhancements, including:

• Support for the SQL MERGE command.
• Selective publication of tables' contents within logical replication publications, through the ability to specify column lists and row filter conditions.
• More options for compression, including support for Zstandard (zstd) compression. This includes support for performing compression on the server side during pg_basebackup.
• Support for structured server log output using the JSON format.
• Performance improvements, particularly for in-memory and on-disk sorting.

Versienummer	15
Releasestatus	Final
Besturingssystemen	Linux, BSD, macOS, Solaris, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website	PostgreSQL
Download	https://www.postgresql.org/download/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (35)

[jochemd]

PostgreSQL is geen afgeleide van Ingres. PostgreSQL is een afgeleide van Postgres. Postgres zelf is volgens THE DESIGN OF POSTGRES uit 1986 een compleet nieuwe ontwikkeling omdat Ingres niet voldeed als databae om nieuwe concepten in te testen:

(..) The University of California version of
INGRES has been ‘‘hacked up enough’’ to make the inclusion of substantial new function
extremely difficult. Another problem with continuing to extend the existing system is that many
of our proposed ideas would be difficult to integrate into that system because of earlier design
decisions. Consequently, we are building a new database system, called POSTGRES (POST
inGRES).

[84hannes]

PostgreSQL is geen afgeleide van Ingres.

Ik was al verbaasd dat ik dat niet wist. Eigenlijk moet ik je naar het feedback-forum verwijzen, maar als je dat (net als velen met jou) omslachtig vindt dan kun je dat hier laten weten met een duimpje.

[MrFax]

Ja, het zit ook letterlijk in de naam, maar je zou het maar moeten weten.

Maar postgres is dus wel weer afgeleid van (of eerder geinspireerd door) ingres. Dus uiteindelijk komt het wel weer terug bij Ingres en is @Drobanir niet helemaal fout.

[Reactie gewijzigd door MrFax op 25 juli 2024 01:48]

[TheVivaldi]

cc @Drobanir

[Argantonis]

Ik zat hier al op te wachten omdat je nu EINDELIJK kan instellen of een null value als een unique value gezien moet worden of niet. Als je dus unique constraints hebt op meerdere velden waarvan er 1 null mag zijn dan werd tot Postgres 14 bijv de combinatie (1, A, null) en (1, A, null) alsnog niet als duplicate gezien. Vanaf Postgres 15 kan je dit instellen in de DDL commands. Zie ook https://news.ycombinator.com/item?id=32053293

[divvid]

Ik zou wel eens willen weten welke usecases nog het gebruik van Oracle en andere commerciële DB’s voor nieuwe projecten rechtvaardigen?

[sanderdw]

Goed punt en ik denk dat die vraag steeds moeilijker te beantwoordenwoorden is, zeker met komst van 'dataplatform ecosystemen' zoals Snowflake en Redshift.

Beheer is denk ik wel een belangrijke hierin, zeker als de infra eromheen ook managed is. Maar ben persoonlijk ook wel eens benieuwd hoe een Postgres nu met dezelfde mem/cpu zich zou verhouden tot SAP Hana, Oracle of SQL server.

Maar uiteindelijk zal je toch per architectuurfunctie (reporting, apps, ml, data pilelines) moeten kijken wat je toepast en zal het steeds meer een mengeling worden.

[kdekker]

Ik denk de (beheer)tooling er omheen. Functioneel zullen de verschillen beperkt zijn, maar zelf merk ik dat bijv profiling/query plans analyseren in SQL server toch wel een stuk beter is dan de (beperkte) explain van PostgreSQL. Wellicht: net wat je gewend bent en waar je kennis zit.

[divvid]

Ook voor PostgreSQL is er tooling beschikbaar, dbForge b.v. Dat Oracle etc. de tooling rondom de daadwerkelijke databases beter op orde heeft staat buiten discussie. De vraag is echter of dit de hoge terugkerende kosten voor de licenties rechtvaardigt. (niet voor niets helpt Oracle met het 'justification' proces).

In de use case waar ik ervaring mee heb (6TB data over een paar honderd tabellen verdeeld) was de overgang naar PostgreSQL (9 destijds, nu op 14) een financiële verademing en kwa performance vergelijkbaar (disks/ssd zijn de limiting factor), maar of dat representatief is weet ik niet door gebrek aan verder vergelijkingsmateriaal (al vermoed ik dat 90% van de databases in Oracle relatief simpel zijn met beperkte of wellicht geen stored procedures). Ook of je veel data tegelijk uit de database moet halen of slechts snippets data (zoals in ons geval) zal wel veel uitmaken.

[cariolive23]

maar zelf merk ik dat bijv profiling/query plans analyseren in SQL server toch wel een stuk beter is dan de (beperkte) explain van PostgreSQL.

Kun je ook aangeven wát er dan beter is? Wat zie je in query plan van SQL Server, wat je niet kan zien in PostgreSQL, en waarom dit toegevoegde waarde heeft.

(Ik heb nauwelijks kennis van SQL Server, mag daar gewoon geen mening over hebben...)

[gekkie]

Ben ik ook wel benieuwd naar.
Een EXPLAIN (ANALYZE) bij PostgreSQL geeft toch wel alle informatie die je zou willen weten. Daarnaast nog pg_stat_statements, auto_explain en co. Ben dan wel benieuwd wat ik allemaal te kort zou komen

[Reactie gewijzigd door gekkie op 25 juli 2024 01:48]

[cariolive23]

En behalve ANALYZE, heb je nog meer settings, settings die je meer informatie verschaffen. ANALYZE heb je uiteraard altijd nodig, anders is een query plan niet meer dan theorie en weet je niet of het nu een goed of een slecht plan is.

[kdekker]

Visualiseren van plans in SQL server management studio laat met de dikte van de lijnen de costs zien. Ik heb ook wel gespeeld met een grafische (online) visualizer van de analyze output (met extra vlaggen ), maar dat was toch minder leesbaar/intuïtief. Speelt ook wel mee dat ik het nog niet vaak met PostgreSQL heb gebruikt.

En ik denk dat enterprise dB's iets meer inzetten op automatische tuning tools.

Dat Oracle duur is, is bekend. Het lijkt wel tactiek te zijn om je zover uit te knijpen dat je net niet wegrent, omdat nog duurder is. Goede reden om zo min mogelijk database specifieke foefjes te gebruiken.

Overigens is er ook nog enterprise DB (EDB). Die bouwt op PostgreSQL extra features, waaronder (al enkele jaren terug) Unicode support. Al lijkt die er ook in plain PostgreSQL te zitten (met ICU).

Een andere feature, die enkele jaren terug niet in PostgreSQL zat, en ik nu niet gebruik, was server based cursors. In SQL server en Oracle was reuse van query plans en cursoren beter. En in DB2 was er een aparte (ongedocumenteerde) connection multiplexer. Daar voldeed postgres niet, maar wel EDB (in Oracle compat mode). Maar goed, je kun je ook afvragen waarom elke end-user minimaal 1 DB connectie nodig had. Een web based applicatie die single shot queries gebruikt heeft een heel ander profiel dan long-running connecties met server-side cursors. Met een net woord zou je dat legacy kunnen noemen (ERP meuk).

In het dagelijks gebruik is PostgreSQL voor ons bedrijf prima werkbaar.

[Reactie gewijzigd door kdekker op 25 juli 2024 01:48]

[jochemd]

Visualiseren van plans in SQL server management studio laat met de dikte van de lijnen de costs zien

Smaken verschillen zulen we maar zeggen: ik vind de visuele representatie in manegement studio een ramp zodra je plan niet superklein is (zeg 5 base tables en 30 nodes). Dan schakel ik ook in management studio over naar de text output.

Overigens is er ook nog enterprise DB (EDB). Die bouwt op PostgreSQL extra features, waaronder (al enkele jaren terug) Unicode support. Al lijkt die er ook in plain PostgreSQL te zitten (met ICU).

Unicode zit al zolang als ik me kan herinneren in PostgreSQL. Hoe lang precies weet ik niet, maar aangezien er in 1998 een regressie test voor unicode werd toegevoegd denk ik dat het meer dan 'enkele jaren' is.

Een andere feature, die enkele jaren terug niet in PostgreSQL zat, en ik nu niet gebruik, was server based cursors.

Als je met 'enkele' 20 bedoelt dan heb je gelijk want die zitten er pas sinds versie 7.2 in.

Voor legacy volwassen systemen is daarnaast natuurlijk een belangrijke reden dat PostgreSQL pas sinds 2005 native op Windows draait. Dat was de eerste paar jaar nog met expliciete waarschuwingen, dus voor veel legacy volwassen systemen zal PostgreSQL ondersteuning geen overweging bij de bouw geweest zijn.

[Reactie gewijzigd door jochemd op 25 juli 2024 01:48]

[kdekker]

Het is een vorige werkkring, maar het product waarvoor ik werkte schakelde pas na 2015 over op EDB. Zo heel ingewikkeld was een driver voor een andere database niet, als je al DB2, informix, sybase, Oracle, Ingres, mssql etc hebt (gehad). Het is enkele jaren geleden voor mij, maar als ik me goed herinner was naast server based cursors ook een controleerbare ICU collation nodig, omdat ook de applicatie zelf sorteert (en dat dat het liefst hetzelfde moet zijn als de database).

[AddictIT]

Ik vermoed enerzijds ecosysteem en featureset (in de zin van integratie met een platform en de gebruikte programmeertaal)

Bv.: Azure - SQLServer - .Net.

Anderzijds beschikbaarheid van mensen die ermee kunnen omgaan en/of beheren.

[Kenhas]

Wat bedoel je hiermee? Voor gebruik met.Net (en EFCore) is het gewoon een kwestie vanhet juiste nuget pakket te installeren

[AddictIT]

Helemaal mee eens, en toch gebeurt het relatief weinig.
Er moet dus een verband zijn dat er in de .NET wereld nog heel vaak naar SQL Server wordt gegrepen.


Kijk bijvoorbeeld naar Bitwarden, die gebruiken ook gewoon SQL Server.

[cariolive23]

En BMW gebruikt PostgreSQL. En ze zoeken nog iemand.

[xFeverr]

Wij hebben een door Azure managed PostgreSQL icm .NET en dat werkt hartstikke goed, en anderzijds kun je ook MSSQL (of AZSQL) gebruiken met andere platformen/talen dan .NET/C# (F#, VB.NET)

Belangrijk bij de keuze is denk ik vooral de features die elke database heeft en hoe de ondersteuning is geregeld. Hoe makkelijk is het beheer. Etc.

[AddictIT]

Daarom dat ik aangaf dat het een combinatie van factoren zal zijn.
Elke database vendor heeft zijn eigenaardigheden of beperkingen.


Ik stel me ook al jaren de vraag waarom PostgreSQL niet (nog) groter/bekender wordt als je ziet hoeveel projecten er nog steeds gebruik maken van MySQL/SQL Server/...

Ik vermoed dat het nog steeds te maken heeft met de voorhanden kennis, niet alleen qua beheer want dat kan (zoals je al aangaf) door een public cloud vendor laten afhandelen.

[xFeverr]

MySQL zit in de bekende LAMP-stack en dat zit zo ingebakken bij de mensen (en bij heel veel hosting providers) dat je dat er maar moeilijk uit gaat krijgen. Het lijkt in het geval van MySQL dus vooral te gaan om naamsbekendheid, weten wat het doet, weten wat je er aan hebt, etc. Daarmee wil niet zeggen dat MySQL persé slecht is, want dat zijn net zo goed geldige redenen als je dat belangrijk vindt.

[gekkie]

Ik stel me ook al jaren de vraag waarom PostgreSQL niet (nog) groter/bekender wordt als je ziet hoeveel projecten er nog steeds gebruik maken van MySQL/SQL Server/...

Bij genoeg opensource projecten, vooral die plugins van derden ondersteunen, wil het nog wel eens zo zijn dat ondanks dat PostgreSQL wordt ondersteund door de core, plugins direct de onderliggende DB kunnen query'en zonder abstractie en dan loop je er tegen aan dat het alleen getest is op Mysql(/Mariadb).

Mijn eigen preferentie is eigenlijk altijd PostgreSQL.

[cariolive23]

Bv.: Azure - SQLServer - .Net.

De Azure - PostgreSQL - .Net. combinatie werkt ook. De programmeertaal is niet zo van belang, de drivers zorgen voor de connectie. Dus of je nou Java, .NET, Python, Perl, PHP of whatever gebruikt, geen enkel probleem.

In de cloud heb je AWS, Azure en GCP die 95% van de cloud markt beheersen en allemaal PostgreSQL aanbieden. Beheer wordt dan ook grotendeels door deze partijen gedaan, is dan niet meer jouw verantwoordelijkheid.

PostgreSQL probeert zoveel mogelijk ANSI SQL te faciliteren, dus wanneer je dat gebruikt in je bestaande code, zal PostgreSQL ook wel werken. Vaak worden ook nog ORM's gebruikt, die gebruiken vaak zulke simpele SQL dat zelfs SQLite er nog wel mee uit de voeten kan...

Kennis van PostgreSQL is uiteraard wel handig, zeker wanneer je performance eisen hebt. De handleiding is zeer compleet en je kunt ook nog altijd kennis (tijdelijk) inhuren. Wanneer je dat goed doet, maak je die kennis direct beschikbaar voor langere tijd in je eigen organisatie.

[AddictIT]

Snap ik, maar dat is geen antwoord op de vraag van @divvid .

Als je het mij vraagt, is PostgreSQL een logische keuze, maar je moet wel de mensen in je team hebben die ermee kunnen omgaan. Zodra je gebruik maakt van een ORM, maakt het allemaal niet veel uit, maar vaak heb je dan niet zo eenvoudig toegang tot de meer specifieke features van een bepaalde database vendor.

En om een of andere reden, krijg je dan veel sneller SQL Server or Oracle of MySQL voor je neus.

[cariolive23]

SQL Server en Oracle kan ik beamen, maar MySQL? Toevallig vorige week een intake gedaan bij een nieuwe klant en bleek nog ergens een MySQL database te gebruiken. Voor mij was dit de eerste keer de afgelopen 3 a 4 jaar. Maar dit ligt waarschijnlijk ook het soort klanten die wij helpen, large enterprise.

[bzzzt]

Grote klanten die 100% op een van de commerciële DB's draaien gaan niet voor een enkel project een alternatieve database invoeren. Als (inhuur) ontwikkelaar heb je daar maar mee te dealen.

[divvid]

ohw?? wat valt onder een grote klant? is >100000 werknemers niet groot genoeg? Juist daar wordt ook op de kleintjes gelet. Bovendien vond de DB admin het destijds wel een uitdaging. Of je nu 1 of 2 grote DB clusters in het rek hebt hangen maakt dan ook niet zo veel meer uit.

Aan de manager/inkoop kant werd het project gebruikt in de onderhandelingen met Oracle. Wat uiteindelijk de uitkomst ook was, de besparing was het waard, al was het alleen al de kennisverhoging van het personeel. In mij huidige non-profit omgeving is elke euro voor een licentie er één teveel overigens.

[Reactie gewijzigd door divvid op 25 juli 2024 01:48]

[cariolive23]

Grote klanten die 100% op een van de commerciële DB's draaien

Zouden ze bestaan? Organisaties die 100% op commerciële database draaien? Ik kom echt in elke organisatie vrijwel elk merk database tegen, bekend, onbekend, groot, klein, open source, closed source, whatever. Zeker in grote organisaties is er altijd wel ergens iemand die iets bedenkt en er mee aan de slag gaat.

Dat juist een van de dingen wat ICT management in grote organisaties zo lastig maakt, al die ongestructureerde ideeën die je toch op de een of andere manier moet zien de ondersteunen.

[vgroenewold]

Ik ben nog niet thuis in SQL databases, maar is dit nu ook een handig iets als je een stand-alone, desktop applicatie maakt waarbij je gegevens wilt bewaren/organiseren? Me lijkt van wel, maar ik hoor eigenlijk alleen maar over remote servers als database.

[cariolive23]

Voor een stand-alone database voor één gebruiker is het een beetje overkill, maar het werkt uiteraard prima. Wanneer je in je eentje aan een kleine database werkt, heb je geen database server nodig. Dan is SQLite al snel goed genoeg, en vaak ook snel genoeg.

Een database server kun je overigens remote gebruiken, maar ook lokaal. Een webserver, applicatieserver en database server kunnen ook allemaal in hun eigen VM draaien, op dezelfde hardware. Keuze genoeg.

[vgroenewold]

Right, ja het is meer dat ik het stand-alone applicatie scenario nooit lees, omdat bijna alles tegenwoordig web-based is als men cross-platform gaat. Mijn doel is om het lokaal te hebben idd, ook omdat gebruikers van de applicatie niet zomaar zoiets op een remote server willen hebben staan. Dank!

[gekkie]

SQLite is daar briljant voor, ook een geniaal stukje opensource-software!

En waarschijnlijk sjouw je er onbewust een hoop van mee in je broekzak (het wordt veel gebruikt in bijvb Android Apps voor data storage). Maar ook bijvb een desktop applicatie als Calibre maakt er gebruik van.

[vgroenewold]

Nice, goed te weten. Als je begint is een goed startpunt wel prettig.

[Artimunor]

Fantastische mijlpaal voor dit geweldig stukje software.
Het gemak waarmee een professionele database ingezet kan worden met een zeer rijk tooling ecosysteem, enorm uitgebreide en makkelijk vindbare online documentatie en user/support groups, maakt dit tot een go-to systeem voor mij en vele anderen.

Ik wacht nog even met upgraden totdat de stabiliteit van deze versie zichzelf bewezen heeft, maar zowel het sorten alsmede de parallel `SELECT DISTINCT` zijn voor mij welkome verbeteringen.