---
url: 'https://sithis.xyz/tutorials/drupal-cms-fuer-selfmade-men-und-macher/postgresql-und-ai'
title: 'Level 4 - Postgresql und AI'
author:
  name: 'Joachim Namyslo'
  url: 'https://sithis.xyz/team/joachim'
  sameAs:
    - 'https://www.youtube.com/@jo_de'
    - 'https://github.com/nodedropweb'
    - 'https://www.drupal.org/u/Joachim-Namyslo'
date: '2026-08-29T19:24:42+00:00'
updated: '2026-09-05T09:00:15+00:00'
type: article
summary: 'MariaDB für Drupal, PostgreSQL mit pgvector für KI: Wir installieren beide Datenbanken sauber getrennt und machen deinen Server AI-ready - ganz ohne Kompromisse beim CMS.'
tags:
  - 'Drupal CMS für Selfmade-Men und Macher'
image: 'https://sithis.xyz/sites/default/files/2026-08/maria-db-installieren_0.jpg'
published: true
og:
  site_name: 'Drupal TV'
  updated_time: '2026-09-05T11:00:15+02:00'
---
# Level 4 - Postgresql und AI

 

**Serie:** Drupal CMS für Selfmade-Men und Macher

## Key Facts

- Zwei Datenbanken, zwei Jobs: MariaDB bedient Drupal, PostgreSQL mit pgvector übernimmt AI-Funktionen wie RAG und semantische Suche.

Erinnerst du dich an den alten Bibliothekar (MariaDB/MySQL)? Er ist zuverlässig, schnell und kennt jedes Buch (Datensatz) in seiner Bibliothek nach Alphabet und ISBN. Drupal liebt ihn. Wir feuern ihn nicht.

Aber was, wenn du ihn fragst: "Gib mir etwas, das sich so *anfühlt* wie ein Sonnenuntergang"? Der alte Bibliothekar zuckt nur mit den Schultern - das ist nicht sein Fachgebiet.

Die Lösung ist kein Umzug, sondern ein Neubau nebenan: Wir stellen zusätzlich **PostgreSQL** mit der Erweiterung **pgvector** ein. Zwei Datenbanken auf einem Server, zwei klar getrennte Jobs: MariaDB verwaltet weiterhin dein Drupal, PostgreSQL kümmert sich exklusiv um alles, was mit Künstlicher Intelligenz (AI) zu tun hat.



Schritte

Warum zwei Datenbanken? (Trennung der Zuständigkeiten)

Man könnte versucht sein, einfach alles auf eine Datenbank zu packen. Aber Drupal Core, die meisten Contrib-Module und fast 20 Jahre Dokumentation sind auf MySQL/MariaDB eingespielt. Warum ein bewährtes Fundament riskieren?

Gleichzeitig ist **pgvector** für Vektorsuche (die Grundlage von RAG - Retrieval Augmented Generation) der Industriestandard. MariaDB lernt das gerade erst, PostgreSQL kann es schon seit Jahren.

Die Lösung: Wir trennen die Zuständigkeiten. MariaDB bleibt der **Bibliothekar für Drupal** (Content, Nutzer, Konfiguration). PostgreSQL wird das **Langzeitgedächtnis für AI-Funktionen** (Embeddings, semantische Suche). Beide laufen friedlich nebeneinander auf demselben Server.



 



Der bewährte Bibliothekar bleibt: MariaDB installieren

Fangen wir mit dem Fundament an, auf dem Drupal am liebsten steht. MariaDB ist ein Fork von MySQL, quelloffen und die von der Drupal-Community am besten getestete Datenbank.

Installieren wir Server, Client und den passenden PHP-Treiber:

```bash
sudo apt install mariadb-server mariadb-client php8.5-mysql -y
```

- mariadb-server: Der eigentliche Datenbank-Dienst.
- mariadb-client: Kommandozeilen-Werkzeug (mysql), um mit dem Server zu sprechen.
- php8.5-mysql: Der Draht, über den Drupal später mit MariaDB redet.



 



Tresor für Drupal: MariaDB absichern und Datenbank anlegen

Frisch installiert ist MariaDB noch offen wie eine Scheune. Wir sichern sie mit dem mitgelieferten Assistenten ab:

```bash
sudo mysql_secure_installation
```

Beantworte die Fragen: Setze ein Root-Passwort, entferne die Test-Datenbank, verbiete Root-Logins von außen. Im Zweifel: Immer mit "Y" (Ja) antworten.

Jetzt legen wir Drupals eigenes Zuhause an. Wir melden uns als Root an:

```bash
sudo mysql -u root -p
```

Und erstellen Benutzer und Datenbank in einem Rutsch:

```sql
CREATE DATABASE drupal_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

CREATE USER 'drupal'@'localhost' IDENTIFIED BY 'DEIN-PASSWORT';

GRANT ALL PRIVILEGES ON drupal_db.* TO 'drupal'@'localhost';

FLUSH PRIVILEGES;

EXIT;
```

Merk dir Benutzername und Passwort gut - Drupal will sie später bei der Installation wissen.



 



Der KI-Spezialist zieht ein: PostgreSQL installieren

Auf Ubuntu 26.04 LTS liegt PostgreSQL 18 bereits in den Regalen. Und das Beste: Die Vektor-Erweiterung liegt auch bereit (im "Universe"-Repository).

Installieren wir den Server, die KI-Erweiterung und - weil PHP jetzt mit zwei Datenbanken gleichzeitig reden muss - auch den passenden Treiber:

```bash
sudo apt install postgresql postgresql-contrib postgresql-18-pgvector php8.5-pgsql -y
```

- postgresql-contrib: Enthält wichtige Zusatz-Tools.
- postgresql-18-pgvector: Der Zauberstab für Vektorsuche.
- php8.5-pgsql: Der zweite Draht - diesmal zu PostgreSQL.



 



Den Tresorraum betreten

PostgreSQL ist strenger als MySQL. Es nutzt standardmäßig keine Passwörter für lokale User, sondern verlässt sich darauf, wer du im Betriebssystem bist (Peer Authentication). Um Befehle zu geben, müssen wir kurz zum System-User postgres werden:

```bash
sudo -i -u postgres
```

Dein Prompt sollte sich ändern (oft zu postgres@...). Du bist jetzt der Datenbank-Administrator - aber diesmal nur für die AI-Abteilung.



 



Ein eigenes Reich für Vektoren: Benutzer und Datenbank erstellen

Wichtig: Diese Datenbank hat nichts mit Drupals drupal\_db in MariaDB zu tun. Sie ist ein separater Raum, ausschließlich für Vektoren und AI-Daten.

1. **User anlegen:** Wir nennen ihn

```sql
createuser --interactive --pwprompt
```

- Gib den Namen der Rolle ein: ai\_user
- Gib das Passwort ein: Wähle ein **sicheres, anderes Passwort** als bei MariaDB. Merk es dir gut!
- Soll die neue Rolle ein "Superuser" sein? -&gt; n (Nein)
- Soll sie Datenbanken erstellen dürfen? -&gt; n (Nein)
- Soll sie Rollen erstellen dürfen? -&gt; n (Nein)

1. **Datenbank anlegen:** Der Name macht deutlich, wofür sie da ist.

```sql
createdb -O ai_user ai_vector_db
```

- -O: Owner (Besitzer).
- ai\_vector\_db: Der Name der Datenbank - bewusst anders als drupal\_db, damit nichts durcheinanderkommt.



 



Die AI-Magie aktivieren (Extension)

Jetzt kommt der Schritt, den die meisten vergessen. Wir müssen die Vektor-Funktion in unserer neuen AI-Datenbank explizit einschalten.

Wir öffnen die SQL-Konsole:

```sql
psql
```

Wir verbinden uns mit der AI-Datenbank (nicht mit drupal\_db!):

```php
\c ai_vector_db
```

(Antwort: You are now connected to database "ai\_vector\_db"...)

Wir aktivieren pgvector:

```sql
CREATE EXTENSION vector;
```

(Antwort: CREATE EXTENSION)

Und zur Sicherheit auch trigram (hilft bei normaler Textsuche enorm):

```sql
CREATE EXTENSION pg_trgm;
```

Verlasse jetzt die Konsole und den postgres-User – das sind **zwei getrennte Schritte**, und beide sind wichtig, sonst scheitert gleich der nächste sudo-Befehl:

1\. Erst die SQL-Konsole verlassen:

```sql
\q
```

Du bist jetzt wieder in der Shell des postgres-Systemusers – **noch nicht** dein normaler User. Verlasse deshalb auch diesen noch:

```bash
exit
```

Kurzer Check, ob du wirklich wieder du selbst bist:

```bash
whoami
```

Steht dort **nicht** postgres, sondern dein eigener Username (z. B. sherpa)? Perfekt – nur dann funktionieren die sudo-Befehle im nächsten Schritt.



 



Authentifizierung prüfen (Der Türsteher)

**Bist du noch als postgres-User unterwegs?** Der folgende Befehl braucht sudo-Rechte deines normalen Users – die hat der postgres-Systemuser nicht. Falls du seit Schritt 7 nicht mehr exit getippt hast, hol das jetzt nach (siehe oben), sonst schlägt der Befehl mit „user postgres is not in the sudoers file“ fehl.

Damit spätere AI-Module sich per Passwort einloggen können, müssen wir sicherstellen, dass Postgres Passwörter (SCRAM-SHA-256) akzeptiert. Das ist in Ubuntu 26.04 meist Standard, aber wir vertrauen nicht, wir prüfen.

Wir schauen kurz in die Config-Datei (als Sudo):

```bash
sudo grep "scram-sha-256" /etc/postgresql/18/main/pg_hba.conf
```

Wenn du Zeilen siehst, die mit host ... scram-sha-256 enden, ist alles gut. PostgreSQL spricht die modernste Verschlüsselung.



 



Firewall-Realitätscheck: Bleiben die Datenbanken unsichtbar?

Wir haben in Level 1 die Firewall (UFW) so eingerichtet, dass sie standardmäßig **alles** blockiert, was nicht explizit erlaubt ist. Für MariaDB (Port 3306) und PostgreSQL (Port 5432) haben wir bewusst **keine** Regel hinzugefügt - und das bleibt auch so.

Beide Datenbanken sollen ausschließlich lokal erreichbar sein, für PHP auf demselben Server. Niemand im Internet braucht direkten Zugriff auf deine Datenbank-Ports. Prüfen wir das:

```bash
sudo ss -tlnp | grep -E ':3306|:5432'
```

In der Ausgabe sollte vor jedem Port nur **127.0.0.1** oder **localhost** stehen - niemals 0.0.0.0 oder deine öffentliche Server-IP. Steht dort etwas anderes, lauscht die Datenbank auf allen Netzwerk-Schnittstellen, und die UFW-Lücke wird zum offenen Scheunentor.

Zur Sicherheit werfen wir auch nochmal einen Blick auf die Firewall selbst:

```bash
sudo ufw status verbose
```

**Steht bei dir stattdessen Status: inactive?** Dann ist UFW zwar installiert, aber nie aktiviert worden – jeder offene Port ist bis dahin ungeschützt erreichbar. Das holst du so nach:

```bash
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
```

Betreibst du neben Drupal noch eigene Dienste auf anderen Ports (z. B. ein eigenes Tool oder eine API)? Dann gib auch diese Ports explizit frei, **bevor** du aktivierst – sonst blockt UFW sie automatisch:

```bash
sudo ufw allow 1234/tcp comment 'mein-dienst'
```

Erst wenn alle benötigten Ports (mindestens OpenSSH!) freigegeben sind, aktivierst du die Firewall:

```bash
sudo ufw enable
```

**Wichtig:** Ohne vorher gesetzte OpenSSH-Regel sperrst du dich per SSH selbst aus. Bestätige den Warnhinweis erst, wenn du sicher bist, dass Port 22 in der Regel-Liste steht.

Siehst du dort weiterhin nur OpenSSH (und ab Level 2 Apache Full)? Dann bleiben deine Datenbanken unsichtbar - genau wie es sein soll.



 



Was haben wir erreicht?

Du hast jetzt zwei Datenbanken auf einem Server, jede spezialisiert auf ihren Job.

- **MariaDB** (der bewährte Bibliothekar) verwaltet deine Drupal-Seite: Inhalte, Nutzer, Konfiguration.
- **PostgreSQL + pgvector** (der neue Spezialist) wartet als *Langzeitgedächtnis* auf Dokumente, die es bald in Bedeutungen statt nur in Buchstaben übersetzen wird.
- **PHP** (Koch) hat mit php8.5-mysql und php8.5-pgsql die passenden Werkzeuge für beide Küchen in der Schublade.

Das Backend steht - mit zwei Beinen statt einem. Aber wer organisiert die Zutaten? Wer holt das Drupal-Paket? Im nächsten Level stellen wir den Logistik-Manager ein.

Bereit für Composer?