Name: Verwaltete Datenbanken von ENTRONYX CLOUD
Brand: ENTRONYX CLOUD

Verwaltete Datenbanken · 9 Engines

9 Datenbank-Engines, 26 Tarife, ein Betriebsmodell. Bereitstellung, Sicherung, Verschlüsselung, Überwachung und Versionswechsel übernehmen wir — bei jeder Engine nach demselben Verfahren. Wo genau die Grenze zwischen Ihrer und unserer Seite verläuft, steht gleich im ersten Abschnitt.

Datenbank konfigurieren Bestand migrieren

Standard ist der private Endpunkt im vRack — dem privaten Netz zwischen Ihren eigenen Servern —, also ohne öffentliche Adresse. TLS, die Verschlüsselung der Verbindung, ist nicht abschaltbar; unverschlüsselte Verbindungen werden abgelehnt.

Engines: 9; relational, Dokument, Cache, Analytik, Suche, Streaming
Einstieg: 47,30 €; Grafana Essential S, monatlich netto
Größter Tarif: 64 GB; RAM, ClickHouse Analytics L
Tarife: 26; über alle Engines

Die Grenze

Was wir übernehmen, was bei Ihnen bleibt

Eine verwaltete Datenbank nimmt Ihnen den Betrieb ab, nicht die Datenmodellierung. Diese beiden Spalten sagen vor allen Tarifen, welcher Teil auf welcher Seite liegt.

Betrieb

ENTRONYX CLOUD übernimmt

In jedem Tarif enthalten, ohne Zusatzvereinbarung.

Bereitstellung: Knoten, Betriebssystem, Engine-Version und Netzanbindung. Sie bekommen eine Verbindungszeichenfolge, keine Maschine zum Einrichten.
Sicherung: Einmal am Tag der vollständige Bestand, dazwischen fortlaufend das Journal, also das Protokoll jeder einzelnen Änderung — verschlüsselt und in einer anderen Region als die Instanz.
Failover: Ab zwei Knoten überwacht ein Wächter die primäre Rolle. Fällt sie aus, übernimmt ein Replikat, typischerweise in unter 30 Sekunden.
Verschlüsselung: AES-256 für gespeicherte Daten, TLS 1.3 für jede Übertragung. Ein Verbindungsversuch ohne TLS wird abgewiesen, nicht stillschweigend zugelassen.
Versionswechsel: Nebenversionen im Wartungsfenster, Hauptversionen nach Vorprüfung. Die Termine kündigen wir an.
Messwerte: Verbindungen, Puffertrefferquote, Replikationsrückstand und Sperrwartezeiten liegen an einem Prometheus-Endpunkt bereit — dem verbreiteten Abfrageformat für Überwachungswerkzeuge.

Anwendung

Sie behalten

Alles, was von Ihrer Anwendung abhängt — und deshalb niemand für Sie entscheiden kann.

Schema und Abfragen: Tabellen, Indizes, Ausführungspläne. Wir sehen die langsame Abfrage im Protokoll — schreiben sie aber nicht um.
Die richtige Größe: Welcher Tarif, wie viele Knoten, wie viele Leseabbilder. Es gibt keine automatische Vergrößerung, die still die Rechnung erhöht.
Wiederverbindung: Nach einem Failover trägt die Verbindungszeichenfolge denselben Namen, aber eine andere Adresse. Ihre Anwendung muss neu verbinden können.
Verbindungsverwaltung: Wie viele Verbindungen Ihr Anwendungspool gleichzeitig offen hält. Die Obergrenze der Instanz ist eine Grenze, kein Ziel.
Zugriffsrechte: Rollen, Passwörter und die Freigabeliste des öffentlichen Endpunkts. Eine leere Liste bedeutet gesperrt, nicht offen.
Archivierung: Die enthaltene Aufbewahrung schützt vor Fehlern der letzten Wochen, nicht vor Aufbewahrungspflichten über Jahre.

Wie viel geht im schlimmsten Fall verloren

Der Wiederherstellungspunkt ist der Abstand zwischen dem letzten sicherbaren Stand und dem Ausfall. Er hängt nicht am Tarif, sondern an der Engine.

3 der 9 Dienste führen zwischen zwei Vollsicherungen ein fortlaufendes Journal und stellen deshalb auf eine frei gewählte Sekunde zurück: PostgreSQL, MySQL, MongoDB. Der Verlust beschränkt sich dort auf die Schreibvorgänge, die das Journal beim Ausfall noch nicht aufgenommen hatte.

Die übrigen 6 Dienste sichern in Momentaufnahmen. Ohne Journal liegt der schlechteste Fall bei einem vollen Tag — 1.440 Minuten zwischen zwei Vollsicherungen. Wer das nicht tragen kann, gehört auf eine Engine mit Journal oder braucht einen zweiten Schreibweg in der Anwendung.

Wie weit zurück — die Stufen aus dem Konfigurator

Die Aufbewahrung bestimmt nicht, wie genau Sie treffen, sondern wie weit Sie zurück können. Beides zusammen ergibt den Schutz: die Genauigkeit aus dem Journal, die Reichweite aus dieser Stufe.

Snapshots (7 Tage): 9,00 €; Tägliche Snapshots, 7 Wiederherstellungspunkte, im ENTRONYX-Netz gespeichert.
Managed Backup (30 Tage): 29,00 €; Tägliche inkrementelle Sicherung, 30 Punkte, georedundant in zweiter Region.
Vault Backup (365 Tage): 79,00 €; Unveränderlicher Speicher mit WORM-Sperre für Compliance-Vorgaben.

Zwei baugleiche Servereinschübe nebeneinander, einer mit grüner, einer mit blauer Statusleuchte. — Replikat · Failover unter 30 s
Ein Replikat ist keine Sicherung. Es hält denselben Stand wie der primäre Knoten — auch den versehentlich gelöschten. Gegen einen Bedienfehler hilft nur die Rückstellung auf einen früheren Zeitpunkt.

Reihe von Laufwerkseinschüben in einem Speicherschrank, Griffmulden im Streiflicht. — Ablage · Sicherung in zweiter Region
Die Datenbank läuft auf lokalen NVMe-Laufwerken — schnellen, direkt an den Knoten angebundenen SSDs. Die Sicherung liegt daneben im Objektspeicher, grundsätzlich in einer anderen Region. Ein Standortausfall trifft bei ENTRONYX CLOUD deshalb nie beides gleichzeitig.

Geöffnetes 2-HE-Servergehäuse von schräg oben auf der Werkbank: Kühlkörper mit Kupferboden über dem Sockel, bestückte und verriegelte Speicherbänke, Lüfterwand, hinten die Netzteile mit Kaltgerätebuchse, an der Front die Laufwerkseinschübe. — Knoten · ECC-Speicher, lokale NVMe-Laufwerke
Jeder Datenbankknoten läuft auf einem Server mit registriertem ECC-Speicher, der gekippte Bits erkennt und korrigiert, bevor sie in eine Tabelle geraten, und mit lokalen NVMe-Laufwerken. Replikate stehen grundsätzlich in getrennten Brandabschnitten — ein Failover findet deshalb auch dann noch einen Knoten, wenn ein ganzer Raum ausfällt.

4 Wörter, die weiter unten vorausgesetzt werden

Replikat: eine mitlaufende zweite Kopie derselben Datenbank auf einem anderen Knoten
Failover: der Wechsel der Schreibrolle auf ein Replikat, wenn der primäre Knoten ausfällt
Point-in-Time-Recovery: die Rückstellung auf eine frei gewählte Sekunde statt nur auf die letzte Sicherung
Verbindungsobergrenze: wie viele Klienten gleichzeitig verbunden sein dürfen; englisch Connection Limit

Auswahl

Erst das Datenmodell, dann der Tarif

Die falsche Engine lässt sich nicht durch mehr Arbeitsspeicher heilen. Diese Übersicht ordnet die sechs Dienste nach dem, was sie speichern und wie darauf zugegriffen wird. Die Größe kommt erst im nächsten Abschnitt.

Übersicht der sechs Datenbankdienste mit Datenmodell, Zugriffsart, typischer Last, Hauptversionen und Einstiegspreis
Dienst	Datenmodell	Zugriff	Typische Last	Versionen	ab
PostgreSQL	relational + JSONB	SQL	OLTP, gemischt	171615	54,46 €
MySQL	relational	SQL	OLTP, lesedominiert	8.48.0	54,46 €
Valkey	Schlüssel-Wert im RAM	RESP-Kommandos	Cache, Sitzungen	8.07.2	107,75 €
MongoDB	Dokumente	MQL, Aggregation	variable Schemata	8.07.0	243,97 €
ClickHouse	spaltenorientiert	SQL	Analytik, Logs	25.324.8	189,00 €
Apache Kafka	verteiltes Log	Producer/Consumer	Ereignisströme	3.93.8	353,03 €

Größen

Vom Datenmodell zur Maschine

26 Tarife über sechs Engines, von 47,30 € bis 1.666,59 € im Monat. Die Wahl hängt an drei Größen: dem Arbeitssatz, dem Datenbestand und der Frage, ob ein Ausfall Minuten oder Sekunden dauern darf.

Alle Tarife aller Engines mit vCPU, Arbeitsspeicher, Speicher, Knotenzahl und Monatspreis, netto
Engine	Tarif	vCPU	RAM	Speicher	Knoten	Monat
PostgreSQL	Essential S	2	4 GB	80 GB	1kein Failover	54,46 €
PostgreSQL	Business M	2	7 GB	160 GB	2	277,25 €
PostgreSQL	Business L	4	15 GB	320 GB	2	554,36 €
PostgreSQL	Enterprise XL	8	30 GB	640 GB	3	1.666,59 €
MySQL	Essential S	2	4 GB	80 GB	1kein Failover	54,46 €
MySQL	Business M	4	15 GB	320 GB	2	554,36 €
MySQL	Enterprise L	8	30 GB	640 GB	3	1.666,59 €
Valkey	Cache S	2	8 GB	nur RAM	1kein Failover	107,75 €
Valkey	Cache M	4	16 GB	nur RAM	2	481,36 €
Valkey	Cache L	8	32 GB	nur RAM	2	962,87 €
MongoDB	Business S	2	8 GB	40 GB	3	243,97 €
MongoDB	Business M	4	16 GB	80 GB	3	483,77 €
MongoDB	Business L	8	32 GB	160 GB	3	941,92 €
ClickHouse	Analytics M	8	32 GB	500 GB	1kein Failover	189,00 €
ClickHouse	Analytics L	16	64 GB	2,0 TB	3	549,00 €
Apache Kafka	Stream S	2	4 GB	480 GB	3	353,03 €
Apache Kafka	Stream M	4	15 GB	1,9 TB	3	1.329,99 €
OpenSearch	Essential S	2	4 GB	40 GB	1kein Failover	59,42 €
OpenSearch	Business M	2	7 GB	240 GB	3	386,10 €
OpenSearch	Business L	4	15 GB	480 GB	3	772,19 €
OpenSearch	Enterprise XL	4	15 GB	960 GB	6	1.564,10 €
Apache Cassandra	Essential S	2	4 GB	40 GB	1kein Failover	96,80 €
Apache Cassandra	Business M	4	15 GB	480 GB	3	867,90 €
Apache Cassandra	Business L	8	30 GB	960 GB	3	1.597,17 €
Grafana	Essential S	2	4 GB	nur RAM	1kein Failover	47,30 €
Grafana	Essential M	2	7 GB	nur RAM	1kein Failover	95,70 €

Die Knotenzahl ist keine Leistungsangabe: Ein zweiter Knoten verdoppelt nicht den Durchsatz, sondern verkürzt den Ausfall. Der größte Tarif führt 64 GB Arbeitsspeicher — genug, um den Arbeitssatz der meisten Anwendungen vollständig im Speicher zu halten.

PostgreSQL

Der relationale Standardfall

Wenn die Anforderung nicht ausdrücklich etwas anderes verlangt, ist das hier die richtige Wahl: feste Schemata, echte Transaktionen, JSONB für alles, was nicht in Spalten passt — und Erweiterungen, die eine zweite Datenbank daneben überflüssig machen.

Der relationale Standardfall

PostgreSQL

Verwaltetes PostgreSQL mit automatischem Failover, Point-in-Time-Recovery und pgvector für Embeddings.

Versionen171615

ab54,46 €im Monat, netto

Dafür wählen

Transaktionale Kernsysteme mit Fremdschlüsseln, Prüfregeln und echten Transaktionen
Gemischte Lasten: relationale Tabellen neben JSONB-Dokumenten in derselben Abfrage
Ähnlichkeitssuche über Embeddings mit pgvector, ohne zweite Datenbank daneben
Geodaten mit PostGIS, Zeitreihen mit nativer Partitionierung nach Bereich

Dafür nicht wählen

Analytische Abfragen über Milliarden Zeilen — dafür ist ClickHouse um Größenordnungen schneller
Als Warteschlange mit hohem Durchsatz; SKIP LOCKED trägt weit, aber nicht bis Kafka
Reiner Sitzungs- oder Seiten-Cache, für den ein RAM-Speicher genügt

Erweiterungen: pgvector, PostGIS, pg_cron, pg_partman
Verbindungspooler: vorgeschaltet, Transaktionsmodus
Lesereplikate: bis 5, auch regionsübergreifend
Wiederherstellungspunkt: sekundengenau (PITR)

Tarife für PostgreSQL: vCPU, Arbeitsspeicher, Speicher, Knotenzahl und Monatspreis
Tarif	vCPU	RAM	Speicher	Knoten	Monat
Essential S	2	4 GB	80 GB	1kein Failover	54,46 €
Business M	2	7 GB	160 GB	2	277,25 €
Business L	4	15 GB	320 GB	2	554,36 €
Enterprise XL	8	30 GB	640 GB	3	1.666,59 €

Datenblätter

MySQL, MongoDB und ClickHouse im Detail

Drei Dienste, die keinen eigenen Abschnitt brauchen, aber dasselbe Datenblatt bekommen: verfügbare Hauptversionen, Tarife mit Ausstattung und Preis sowie eine ehrliche Abgrenzung — wofür sie gebaut wurden und wofür ausdrücklich nicht.

Relational

Festes Schema, Fremdschlüssel und Transaktionen — hier in der Ausführung für gewachsene Anwendungen, die MySQL sprechen und es auch weiter sprechen sollen.

Für gewachsene Anwendungen

MySQL

Verwaltetes MySQL mit InnoDB-Cluster, Lesereplikaten und automatischen Backups.

Versionen8.48.0

ab54,46 €im Monat, netto

Dafür wählen

Bestehende Anwendungen aus dem PHP-, WordPress- und Magento-Umfeld ohne Portierungsaufwand
Lesedominierte Lasten, die über Replikate horizontal wachsen
InnoDB-Cluster mit Gruppenreplikation und automatischer Primärwahl

Dafür nicht wählen

Komplexe analytische Abfragen mit Fensterfunktionen über große Datenmengen
Anwendungen, die auf PostgreSQL-Erweiterungen wie pgvector oder PostGIS bauen
Neue Projekte ohne MySQL-Bindung — PostgreSQL bietet dort mehr für denselben Preis

Zeichensatz: utf8mb4, Kollation utf8mb4_0900_ai_ci
Replikation: GTID-basiert, halbsynchron
Journal: Binlog, ROW-Format, 7 Tage
Wiederherstellungspunkt: sekundengenau (PITR)

Tarife für MySQL: vCPU, Arbeitsspeicher, Speicher, Knotenzahl und Monatspreis
Tarif	vCPU	RAM	Speicher	Knoten	Monat
Essential S	2	4 GB	80 GB	1kein Failover	54,46 €
Business M	4	15 GB	320 GB	2	554,36 €
Enterprise L	8	30 GB	640 GB	3	1.666,59 €

Schemafrei

Struktur je Datensatz statt je Tabelle. Für Daten, deren Felder sich zwischen zwei Einträgen unterscheiden dürfen.

Wenn das Schema wandert

MongoDB

Dokumentendatenbank mit Replica-Set, Aggregation-Pipeline und Atlas-kompatibler Treiber-API.

Versionen8.07.0

ab243,97 €im Monat, netto

Dafür wählen

Katalog- und Produktdaten mit stark unterschiedlichen Feldern je Eintrag
Ereignis- und Telemetriedaten, deren Struktur sich über die Zeit ändert
Anwendungen, die Aggregations-Pipelines statt SQL schreiben

Dafür nicht wählen

Stark verknüpfte Modelle mit vielen Beziehungen — $lookup ist kein JOIN
Berichte über den gesamten Datenbestand; dafür fehlt die spaltenorientierte Ablage
Buchhalterische Konsistenz über viele Dokumente hinweg; Transaktionen gibt es, sie sind aber teuer

Topologie: Replica Set mit drei Knoten
Treiber-API: kompatibel zu den offiziellen Treibern
Wiederherstellung: Oplog-basiert, sekundengenau
Indizes: zusammengesetzt, Text, Geo, TTL

Tarife für MongoDB: vCPU, Arbeitsspeicher, Speicher, Knotenzahl und Monatspreis
Tarif	vCPU	RAM	Speicher	Knoten	Monat
Business S	2	8 GB	40 GB	3	243,97 €
Business M	4	16 GB	80 GB	3	483,77 €
Business L	8	32 GB	160 GB	3	941,92 €

Analytik

Nicht für den einzelnen Datensatz gebaut, sondern für den Durchsatz über Milliarden davon.

Analytik in Sekundenbruchteilen

ClickHouse

Spaltenorientierte Analysedatenbank für Milliarden Zeilen mit Antwortzeiten unter einer Sekunde.

Versionen25.324.8

ab189,00 €im Monat, netto

Dafür wählen

Auswertungen über Milliarden Zeilen mit Antwortzeiten unter einer Sekunde
Log-, Metrik- und Klickstromdaten mit hoher Kompression
Materialisierte Sichten, die beim Schreiben vorverdichten

Dafür nicht wählen

Transaktionale Lasten mit einzelnen Aktualisierungen und Löschungen je Zeile
Sehr viele gleichzeitige Punktabfragen — der Optimierer ist auf Durchsatz gebaut, nicht auf Parallelität
Referenzielle Integrität; Fremdschlüssel existieren nicht

Tabellen-Engine: MergeTree-Familie, Standard ReplicatedMergeTree
Kompression: ZSTD, typisch Faktor 8 bis 12
Schnittstellen: HTTP, natives Protokoll, MySQL-Port
Aufnahme: Kafka-Engine für direkten Zufluss

Tarife für ClickHouse: vCPU, Arbeitsspeicher, Speicher, Knotenzahl und Monatspreis
Tarif	vCPU	RAM	Speicher	Knoten	Monat
Analytics M	8	32 GB	500 GB	1kein Failover	189,00 €
Analytics L	16	64 GB	2,0 TB	3	549,00 €

Valkey

Arbeitsspeicher mit Netzanschluss

Valkey ist die offene Fortführung von Redis: dasselbe Protokoll, dieselben Treiber, dieselben Datenstrukturen — unter einer Lizenz, die den Betrieb als verwalteten Dienst ausdrücklich erlaubt. Bestehende Redis-Clients verbinden sich ohne Anpassung.

Dafür wählen

Versionen8.07.2

Sitzungsverwaltung, Objekt-Cache, Ratenbegrenzung und verteilte Sperren
Veröffentlichen und Abonnieren sowie leichte Warteschlangen über Streams
Bestenlisten und Zähler mit sortierten Mengen bei sehr hoher Anfragerate

Dafür nicht wählen

Primäre Ablage von Daten, deren Verlust nicht hinnehmbar ist
Datenmengen, die größer sind als der Arbeitsspeicher des Tarifs
Abfragen über Beziehungen — es gibt keine Verknüpfungen und keine Indizes über Werte

Persistenz: AOF jede Sekunde, RDB stündlich
Kein Blockspeicher: Datensatz muss in den RAM passen
Cluster-Modus: ab drei Knoten, 16.384 Slots
Protokoll: RESP3, Redis-Treiber kompatibel

Speicherklassen

Es gibt keinen Blockspeicher zum Dazubuchen: Der Arbeitsspeicher des Tarifs ist die Kapazität. Passt der Datensatz nicht hinein, ist nicht der Tarif zu klein, sondern die Engine falsch gewählt.

Speicherklassen von Valkey. Der Arbeitsspeicher ist zugleich die nutzbare Kapazität — die Spalte „Speicher“ fehlt hier nicht, es gibt sie nicht.
Tarif	vCPU	Arbeitsspeicher	Knoten	Typischer Einsatz	Monat
Cache S	2	8 GB	1kein Failover	Sitzungen und Objekt-Cache einer einzelnen Anwendung	107,75 €
Cache M	4	16 GB	2	Gemeinsamer Cache mehrerer Dienste, Ratenbegrenzung, Sperren	481,36 €
Cache L	8	32 GB	2	Bestenlisten und Zähler mit sehr hoher Anfragerate	962,87 €

Persistenzmodus

Zwei Verfahren laufen gleichzeitig. Das Anfügeprotokoll (AOF) schreibt jede verändernde Anweisung mit und wird einmal je Sekunde auf das Laufwerk gezwungen. Der Schnappschuss (RDB) schreibt stündlich ein vollständiges Abbild des Speichers.

Beim Neustart eines Knotens wird aus dem Anfügeprotokoll wieder eingelesen — der Verlust beträgt dann höchstens die letzte Sekunde. Bei einer Wiederherstellung aus der Sicherung ist der Bezugspunkt dagegen der letzte Schnappschuss, also bis zu eine Stunde. Das ist kein Fehler in der Einstellung, sondern der Preis dafür, dass ein Speicher im Arbeitsspeicher kein Transaktionsjournal führt.

Die praktische Regel daraus: Alles, was Valkey enthält, muss sich aus einer anderen Quelle neu aufbauen lassen. Ist das nicht der Fall, gehören die Daten in PostgreSQL und nur ihre Kopie hierher.

Abgrenzung zu Kafka

Beide kennen Ströme und Konsumentengruppen, und genau deshalb werden sie verwechselt. Der Unterschied liegt nicht in der Schnittstelle, sondern darin, wo die Daten liegen und wie lange.

Valkey Streams und Apache Kafka im Vergleich — Ablage, Vorhaltung, Verteilung und Betriebsaufwand
Merkmal	Valkey Streams	Apache Kafka
Ablage	im Arbeitsspeicher	auf Platte, im Tarif enthalten
Vorhaltung	über MAXLEN begrenzt, sonst wächst der Speicherbedarf	nach Zeit oder Größe, je Topic einstellbar
Zurückspulen	bis zum ältesten noch vorhandenen Eintrag	bis zum Beginn der Vorhaltung, beliebig oft
Verteilung	Cluster-Modus ab drei Knoten, 16.384 Slots	Partitionen je Topic, Führer je Partition
Schema	keine Registry, Inhalt ist Sache der Anwendung	Schema-Registry enthalten (Avro, Protobuf, JSON Schema)
Betriebsaufwand	eine Verbindungszeichenfolge, keine Topologie	Topics, Partitionen, Konsumentengruppen zu planen
Einstieg im Monat	107,75 €	353,03 €
Obergrenze der Datenmenge	32 GB Arbeitsspeicher	1,9 TB Speicher im größten Tarif

Ereignisströme

Kafka: was passiert ist, nicht was gerade gilt

Ein verteiltes Protokoll statt einer Tabelle. Jeder Eintrag bleibt liegen, bis die Vorhaltung endet — und jeder Verbraucher liest ihn in seinem eigenen Tempo. Ab 353,03 € im Monat, immer mit 3 Knoten, weil ein einzelner Broker kein Protokoll absichert.

Ereignisse statt Zustände

Apache Kafka

Verwaltetes Event-Streaming mit KRaft-Modus, Schema-Registry und Connect-Runtime.

Versionen3.93.8

ab353,03 €im Monat, netto

Dafür wählen

Entkopplung von Diensten, die nicht zur selben Zeit erreichbar sein müssen
Change Data Capture aus Datenbanken über Debezium und die Connect-Laufzeit
Wiederholbare Verarbeitung: Konsumenten spulen zurück, ohne die Quelle zu belasten

Dafür nicht wählen

Anfrage-und-Antwort-Muster; Kafka kennt keine Rückkanäle
Abfragen über Inhalte — es gibt keinen Index, nur Offsets und Partitionen
Kleine Systeme mit wenigen Ereignissen je Sekunde; der Betriebsaufwand lohnt sich dort nicht

Betriebsmodus: KRaft, ohne ZooKeeper
Schema-Registry: enthalten, Avro, Protobuf, JSON Schema
Vorhaltung: nach Zeit oder Größe, je Topic
Verschlüsselung: TLS und SASL/SCRAM erzwungen

Tarife für Apache Kafka: vCPU, Arbeitsspeicher, Speicher, Knotenzahl und Monatspreis
Tarif	vCPU	RAM	Speicher	Knoten	Monat
Stream S	2	4 GB	480 GB	3	353,03 €
Stream M	4	15 GB	1,9 TB	3	1.329,99 €

Gemeinsame Merkmale

Was für jede Engine gilt

Betriebseigenschaften unterscheiden sich weniger zwischen den Diensten als die Datenmodelle. Wo es doch Unterschiede gibt, stehen sie in der Tabelle — nicht im Kleingedruckten. Sicherung und Wiederherstellung stehen im eigenen Abschnitt darunter.

Automatisches Failover

Bei mehrknotigen Tarifen überwacht ein Wächter die primäre Rolle. Fällt sie aus, übernimmt ein Replikat; die Umschaltung dauert typischerweise unter 30 Sekunden. Die Verbindungszeichenfolge zeigt auf einen Namen, nicht auf eine Adresse — Ihre Anwendung braucht nur eine Wiederverbindungslogik.

Verschlüsselung

Ruhende Daten liegen AES-256-verschlüsselt auf NVMe, Sicherungen zusätzlich im Object Storage verschlüsselt. Im Transit gilt TLS 1.3 mit Zertifikatsprüfung; ein Verbindungsversuch ohne TLS wird abgewiesen, nicht stillschweigend zugelassen.

Private Netzanbindung

Jede Instanz bekommt einen Endpunkt im vRack 1 Gbit/s und standardmäßig keine öffentliche Adresse. Wer von außen zugreifen muss, schaltet den öffentlichen Endpunkt frei und hinterlegt eine Freigabeliste — leer bedeutet gesperrt, nicht offen.

Metriken und Protokolle

Ein Prometheus-kompatibler Endpunkt liefert Verbindungen, Puffertrefferquote, Replikationsrückstand und Sperrwartezeiten. Langsame Abfragen landen im Protokoll und in der Konsole, mit Ausführungsplan.

Betriebseigenschaften je Engine — dort, wo sie sich unterscheiden
Merkmal	PostgreSQL	MySQL	Valkey	MongoDB	ClickHouse	Apache Kafka	OpenSearch	Apache Cassandra	Grafana
Failoverab zwei Knoten	Patroni, < 30 s	Gruppenreplikation, < 30 s	Sentinel bzw. Cluster-Modus	Replica Set, Wahl in < 15 s	Replikat übernimmt Shard	Partitionsführer wechselt automatisch
Lesereplikate	bis 5, regionsübergreifend	bis 5	im Cluster-Modus	im Replica Set	über Shard-Replikate	über Konsumentengruppen
Speicher im Tarif	bis 640 GB	bis 640 GB	nur RAM	bis 160 GB	bis 2,0 TB	bis 1,9 TB	bis 960 GB	bis 960 GB	nur RAM
Hauptversionswechsel	im Wartungsfenster, mit Vorprüfung	im Wartungsfenster, mit Vorprüfung	rollierend, ohne Ausfall	rollierend, ohne Ausfall	rollierend, ohne Ausfall	rollierend, ohne Ausfall
VerbindungsobergrenzeRichtwert 4 × vCPU + 100	Pooler vorgeschaltet	Pooler vorgeschaltet	10.000 gleichzeitig	Treiber-Pool je Anwendung	auf Durchsatz ausgelegt, nicht auf Parallelität	unbegrenzt, Partitionsanzahl ist die Grenze

Reihe verschlossener Speicherkassetten in einem Regal, eine davon halb herausgezogen. — ENTRONYX CLOUD sichert einmal am Tag vollständig und schreibt dazwischen das Journal mit. Jeden Monat wird eine Stichprobe tatsächlich zurückgespielt — eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung.
Sicherung · täglich, Prüfung monatlich

Sicherung

Täglich vollständig, dazwischen das Journal

Eine Sicherung, die niemand zurückgespielt hat, ist eine Vermutung. Deshalb läuft die Wiederherstellung hier nicht nur im Ernstfall, sondern monatlich stichprobenhaft — und immer in eine neue Instanz, nie über die laufende.

01
Vollsicherung
täglich
Einmal je Tag wird der vollständige Datenbestand gesichert und verschlüsselt im Object Storage abgelegt — grundsätzlich in einer anderen Region als die Instanz selbst.
02
Journal
fortlaufend
Zwischen zwei Vollsicherungen läuft das Transaktionsjournal mit. Es schließt die Lücke zwischen dem letzten vollständigen Abbild und dem Zeitpunkt, den Sie später auswählen.
03
Aufbewahrung
14 Tage, auf Wunsch bis 365
Vierzehn Tage sind in jedem Tarif enthalten. Für Aufbewahrungspflichten verlängern wir auf bis zu 365 Tage; abgerechnet wird der zusätzlich belegte Speicher.
04
Wiederherstellung
in eine neue Instanz
Sie wählen einen Zeitpunkt, wir stellen daraus eine zweite Instanz her. Die laufende bleibt unangetastet — der Vergleich beider Stände ist damit Teil des Verfahrens und nicht sein Risiko.
05
Prüfung
monatlich
Jeden Monat wird eine Stichprobe tatsächlich zurückgespielt und gegen die Quelle geprüft. Was dabei auffällt, ist ein Betriebsvorgang und keine Entdeckung im Ernstfall.

Wiederherstellungspunkt und Verfahren je Engine
Engine	Wiederherstellungspunkt	Verfahren
PostgreSQL	sekundengenau	Basissicherung und fortlaufendes WAL-Journal
MySQL	sekundengenau	Vollsicherung und Binlog im ROW-Format, 7 Tage
Valkey	letzter Schnappschuss	RDB stündlich, Anfügeprotokoll je Sekunde
MongoDB	sekundengenau	Vollsicherung und Oplog
ClickHouse	letzte Sicherung	Vollsicherung je Partition
Apache Kafka	Vorhaltung statt Wiederherstellung	Ereignisse bleiben im Topic lesbar

Zugriff und Netz

Wie eine Instanz erreichbar wird

Eine verwaltete Datenbank ist erst dann verwaltet, wenn auch der Weg zu ihr festgelegt ist. Standard ist deshalb: privat, verschlüsselt, mit getrennten Rollen — und nichts davon lässt sich versehentlich abschalten.

Jede Instanz erhält einen Namen im internen DNS und einen Endpunkt im vRack 1 Gbit/s — kein öffentlicher A-Record, keine erreichbare Adresse im Internet. Wer von außen zugreifen muss, schaltet den öffentlichen Endpunkt ausdrücklich frei und hinterlegt eine Freigabeliste. Eine leere Liste bedeutet gesperrt, nicht offen.

Bandbreiten des privaten Netzes und deren monatlicher Aufpreis, netto
Privates Netz	Einsatz	Aufpreis
vRack 1 Gbit/s	Isoliertes Layer-2-Netz über alle Standorte hinweg.	enthalten
vRack 10 Gbit/s	Für Storage-Replikation und Datenbank-Cluster.	39,00 €
vRack 25 Gbit/s	Dedizierte Fabric für HPC- und Hypervisor-Cluster.	119,00 €
vRack 50 Gbit/s	Für verteilte Speicherpools, deren Schreibpfad über das private Netz läuft.	219,83 €
vRack 100 Gbit/s	Höchste Ausbaustufe für Verbünde mit synchroner Replikation zwischen Brandabschnitten.	421,49 €

Verbinden, wiederherstellen, replizierenSHELL

# Verbindungszeichenfolge holen — TLS ist Pflicht, nicht Option
entronyx db uri shop-pg --role app
# postgresql://app:…@shop-pg.fra1.db.entronyx.internal:5432/app?sslmode=verify-full
 
# Wiederherstellung auf einen Zeitpunkt innerhalb der Aufbewahrung
entronyx db restore shop-pg \
  --point-in-time "2026-08-27T21:14:05Z" \
  --target shop-pg-restore
 
# Lesereplikat in einer zweiten Region anhängen
entronyx db replica create shop-pg --region hel1 --plan pg-m

sslmode=verify-full ist voreingestellt. Das Wurzelzertifikat liegt in jedem Abbild unter /etc/ssl/certs/entronyx-db.pem und wird über die Paketquelle aktualisiert.

Drei Rollen je Instanz

admin: Legt Datenbanken, Schemata und weitere Rollen an. Gehört in den Bereitstellungslauf, nicht in die Anwendung.
app: Lesen und Schreiben in genau einer Datenbank. Das ist die Rolle, die in Ihrer Verbindungszeichenfolge steht.
readonly: Nur Lesen, standardmäßig gegen ein Replikat. Für Berichte, Exporte und Analysewerkzeuge.

Jede Rolle hat ein eigenes Passwort, das sich einzeln erneuern lässt. Eine Anwendung, die mit admin verbindet, ist ein Befund, kein Betriebszustand.

Umzug

Bestehende Datenbanken migrieren

Der Weg ist bei jeder Engine derselbe: einmal vollständig übertragen, dann fortlaufend nachziehen, bis der Rückstand null ist, und erst dann umschalten. Ein Dump um Mitternacht ist keine Migration, sondern eine Wette.

01
Bestandsaufnahme
1 bis 2 Stunden
Größe je Tabelle, verwendete Erweiterungen, Zeichensatz und Kollation, Rollen und Rechte, Anzahl gleichzeitiger Verbindungen, längste laufende Abfrage. Alles, was auf der Quelle besonders ist, wird hier sichtbar — nicht erst beim Einspielen.
02
Zieltarif wählen
Arbeitssatz zählt
Arbeitsspeicher mindestens so groß wie der häufig gelesene Teil der Daten, Speicher etwa das Anderthalbfache des Bestands, Knotenzahl nach Ausfallanforderung. Nach oben lässt sich später wechseln, nach unten nicht immer.
03
Erstübertragung
abhängig von der Datenmenge
Dump oder Basissicherung, parallel eingespielt. Eigentümer und Rechte der Quelle werden dabei bewusst weggelassen und im Ziel neu vergeben — sonst schleppen Sie Rollen mit, die es hier nicht gibt.
04
Fortlaufend nachziehen
Stunden bis Tage
Logische Replikation, GTID-Replikation oder Change Streams halten das Ziel aktuell, während die Quelle weiterarbeitet. In dieser Phase testen Sie die Anwendung bereits gegen das Ziel — nur lesend.
05
Umschaltung
Wartungsfenster, wenige Minuten
Schreibzugriffe auf der Quelle anhalten, warten bis der Rückstand null ist, Verbindungszeichenfolge tauschen, Sequenzen prüfen, Schreibzugriffe freigeben. Wer den Rückstand nicht misst, verliert Datensätze.
06
Rückweg offenhalten
7 Tage
Die Quelle bleibt eine Woche lang unverändert stehen. Das kostet wenig und ist der einzige belastbare Rollback-Plan, den es bei einer Migration gibt.

PostgreSQL-Migration mit logischer ReplikationSHELL

# 1. Zielinstanz anlegen, privater Endpunkt im vRack
entronyx db instance create shop-pg \
  --engine postgresql --version 17 --plan pg-m \
  --region fra1 --vrack prod --no-public-endpoint
 
# 2. Schema und Daten übertragen, ohne Eigentümer und Rechte der Quelle
pg_dump --no-owner --no-privileges --format=directory --jobs=4 \
  --dbname="$SOURCE_URL" --file=/tmp/dump
 
pg_restore --no-owner --jobs=4 \
  --dbname="$(entronyx db uri shop-pg --role admin)" /tmp/dump
 
# 3. Fortlaufend nachziehen, bis der Rückstand null ist
psql "$SOURCE_URL" -c "CREATE PUBLICATION migration FOR ALL TABLES;"
psql "$(entronyx db uri shop-pg)" -c \
  "CREATE SUBSCRIPTION migration CONNECTION '$SOURCE_URL' PUBLICATION migration;"
 
# 4. Rückstand messen — erst bei 0 Bytes umschalten
psql "$(entronyx db uri shop-pg)" -c \
  "SELECT application_name,
          pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
     FROM pg_stat_replication;"
 
# 5. Nach der Umschaltung aufräumen
psql "$(entronyx db uri shop-pg)" -c "DROP SUBSCRIPTION migration;"

Für MySQL tritt an die Stelle von Schritt 3 eine GTID-basierte Replikation, für MongoDB mongosync mit Change Streams. Das Muster bleibt identisch.

Werkzeuge und realistische Ausfallzeit je Engine
Engine	Erstübertragung	Fortlaufend	Ausfall
PostgreSQL	pg_dump / pg_basebackup	logische Replikation	< 5 min
MySQL	MySQL Shell, util.copyInstance	GTID-Replikation	< 5 min
Valkey	RDB-Datei einspielen	REPLICAOF gegen die Quelle	< 1 min
MongoDB	mongodump / mongorestore	mongosync, Change Streams	< 10 min
ClickHouse	INSERT … SELECT über remoteSecure()	Nachlauf je Partition	Minuten bis Stunden
Apache Kafka	MirrorMaker 2	MirrorMaker 2 mit Offset-Übersetzung	ohne Ausfall

Nächster Schritt

Datenbank bereitstellen oder Bestand migrieren

Eine Instanz steht in wenigen Minuten, mit privatem Endpunkt, erzwungenem TLS und laufender Sicherung ab der ersten Minute. Für den Umzug bestehender Systeme gibt es einen Leitfaden und auf Wunsch Begleitung durch unsere Techniker.

Datenbank konfigurieren Migration besprechen

Engines: 9
ab: 47,30 €
Tarife: 26
Failover: < 30 s

Sie schreiben Abfragen,wir halten sie am Laufen

Was wir übernehmen, was bei Ihnen bleibt

ENTRONYX CLOUD übernimmt

Sie behalten

Wie viel geht im schlimmsten Fall verloren

Wie weit zurück — die Stufen aus dem Konfigurator

4 Wörter, die weiter unten vorausgesetzt werden

Erst das Datenmodell, dann der Tarif

Vom Datenmodell zur Maschine

Der relationale Standardfall

PostgreSQL

Dafür wählen

Dafür nicht wählen

MySQL, MongoDB und ClickHouse im Detail

MySQL

Dafür wählen

Dafür nicht wählen

MongoDB

Dafür wählen

Dafür nicht wählen

ClickHouse

Dafür wählen

Dafür nicht wählen

Arbeitsspeicher mit Netzanschluss

Dafür wählen

Dafür nicht wählen

Speicherklassen

Persistenzmodus

Abgrenzung zu Kafka

Kafka: was passiert ist, nicht was gerade gilt

Apache Kafka

Dafür wählen

Dafür nicht wählen

Was für jede Engine gilt

Automatisches Failover

Verschlüsselung

Private Netzanbindung

Metriken und Protokolle

Täglich vollständig, dazwischen das Journal

Vollsicherung

Journal

Aufbewahrung

Wiederherstellung

Prüfung

Wie eine Instanz erreichbar wird

Bestehende Datenbanken migrieren

Bestandsaufnahme

Zieltarif wählen

Erstübertragung

Fortlaufend nachziehen

Umschaltung

Rückweg offenhalten

Datenbank bereitstellen oder Bestand migrieren