Nicht nur Oracles Politik der eisernen Faust hat mich gegen jede Vernunft (und gut gemeinte Warnungen) einen Versuch mit PostgreSQL machen lassen. Die Sirenenklänge von reliability, data integrity, and correctness
und das Durcheinander von Storage Engines führen schon seit Monaten dazu, dass ich mich nur halbherzig mit table_cache, query_cache_size und key_buffer_size beschäftige. Warum sollte man auch einen halbwegs reibungslos laufenden Datenbankserver optimieren, wenn als Alternative ein System bereitsteht, dem nur SQL-Gurus inkonsistente Daten unterjubeln können und das die Dokumentation nicht in einem obskuren Developer-Bereich versteckt?
Entgegen der Behauptung optimistischer Anleitungen erweist sich die Übertragung von Daten zwischen den beiden OS-RDBMSs natürlich trotz des hilfreichen Kompatibilitätsmodus (--compatible=postgresql) von mysqldump als nicht ganz trivial: Zeichenketten mit escape characters wollen mit E
präfigiert werden, das Repertoire von Feldtypen ist nicht deckungsgleich, LOCK/UNLOCK-Anweisungen werden von PostgreSQL zurückgewiesen, und zu allem Überfluss ordnet Djangos syncdb-Anweisung die Spalten für eine bestimmte Tabelle in PostgreSQL anders an als in der Ausgangsdatenbank.
Angesichts all dieser Widrigkeiten ziehe ich mich auf eine bekannte Kompromissformel zurück: I'll be back.