Ich finde die Frage verwirrend.
Meistens wird unter "NoSQL" ja letztendlich entweder eine Key/Value Datenbank (z.B. wie Redis) oder eine Dokumenten orientierte Datenbank (wie MongoDB). Und dann gibt es noch einige andere (Graph Datenbanken z.B.)
Häufig wird es aber mit "kann JSON speichern" gleichgesetzt (was dem sehr weit gefassten Begriff "NoSQL" aber nicht ganz gerecht wird - schließlich umfasst das einfach alle nicht-relationalen Datenbanken).
Ich denke wenn man "NoSQL-Features" mit "JSON Features" gleichsetzt, dann dürfte Postgres (in der Summe aller Features) ziemlich weit vorne mitspielen. Oracle 19 und SQL Server 2019 sind allerdings ziemlich dicht dran - aber man findet sicherlich immer ein Feature welches ausgerechnet in System X nicht vorhanden ist.
Soweit ich das beurteilen kann, hat Postgres aber die Nase deutlich vor, wenn es um das Indizieren von JSON Werten geht. Bei MySQL und SQL Server muss man z.B. für jede Bedingung die man indizieren möchte, eine berechnete Spalte anlegen und diese dann indizieren. Damit hat man aber nur die bekannten Bedingungen abgedeckt. Wenn man die Struktur des JSON nicht genau kennt, dann wird es fast unmöglich das zu indizieren. Such' mal nach einer Präsentation die "How to Use JSON in MySQL Wrong" heißt - praktisch alles da drin ist für Postgres
nicht relevant.
Oracle hat ein ähnliches Konzept wie Postgres: dort kann man "generalisierte" Indizes anlegen (nennt sich Context Index) um Abfragen auf JSON Werte zu beschleunigen deren Struktur man nicht kennt. Im Gegensatz zu Postgres kann dabei sogar eine Abfrage die eine Subquery verwendet von dem Index profitieren (
where exists (select ... from json_table(...)
). Context Indizes werden in Oracle auch für der Volltextsuche eingesetzt und meine Erfahrung damit war eher negativ, weil die Indizes sehr viel "Zuwendung" benötigt haben, um das System am Laufen zu halten. Das war aber noch mit Oracle 11 und 12 - keine Ahnung ob die bei Oracle 19 oder 21 immer noch so fragil sind.
json_table()
analog zu
xml_table()
fehlt leider auch noch in Postgres, aber in den meisten Fällen kann man das Gleiche auch mit mit
jsonb_each()
erreichen.
Was die Unterstützung von SQL Features aus dem SQL Standard betrifft, dürfte Oracle wohl derzeit die Nase vorn haben:
Oracle DB 19c Improves JSON Standard Conformance
Allerdings ist die Übersicht dort etwas irreführend: für die meisten Funktionen des SQL Standard hat Postgres eine entsprechende Funktion - die halt etwas anders heißt und etwas anders verwendet wird. Wobei die Trennung zwischen den Typen
json
und
jsonb
die Sache in Postgres nicht leichter macht. Ich hätte mir echt gewünscht, dass alle JSON Funktionen transparent json/jsonb als Argumente verwenden könnten (und es nicht immer eine json_xxx und jsonb_xxx Funktion gibt).
Man sollte aber nie vergessen: Postgres ist und bleibt eine relationale Datenbank. Auch wenn es eine starke JSON Unterstützung gibt, wird sich das nie wirklich "gut" anfühlen. Vor allem das
Ändern von einzelnen Werten in einer großen JSON Struktur ist in einer relationalen DB immer recht umständlich.