<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Migrating from mysql to postgresql]]></title><description><![CDATA[<p dir="auto">How can I migrate my FusionAuth installation from mysql to postgresql?</p>
]]></description><link>https://fusionauth.io/community/forum/topic/985/migrating-from-mysql-to-postgresql</link><generator>RSS for Node</generator><lastBuildDate>Tue, 08 Sep 2026 03:49:50 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/topic/985.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 28 Apr 2021 14:50:13 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Migrating from mysql to postgresql on Sun, 27 Nov 2022 22:18:22 GMT]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/826">@sander</a></p>
<p dir="auto">Thanks for the update. We're bummed that we can't include the mysql connector as part of the docker image.</p>
<p dir="auto">If FusionAuth is stuck in maintenance mode, this thread might prove useful: <a href="https://fusionauth.io/community/forum/topic/135/can-t-get-by-maintenance-mode">https://fusionauth.io/community/forum/topic/135/can-t-get-by-maintenance-mode</a></p>
<p dir="auto">Can you give me any more details about the issue?</p>
]]></description><link>https://fusionauth.io/community/forum/post/5698</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/5698</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Sun, 27 Nov 2022 22:18:22 GMT</pubDate></item><item><title><![CDATA[Reply to Migrating from mysql to postgresql on Thu, 17 Nov 2022 12:56:38 GMT]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/20">@dan</a> I have tried this migration,</p>
<p dir="auto">There are 2 things that are not working, after migration the data is not in the public schema,</p>
<p dir="auto">If i mitigate that by renaming public to public_old then the fusionauth schema to public and then delete the obselete schema.</p>
<p dir="auto">When i fire up Fusionauth it gets stuck in maintenance mode.</p>
<p dir="auto">We would really like to migrate to Postgres especially considering the new MySQL connector is not part of the docker image anymore.</p>
]]></description><link>https://fusionauth.io/community/forum/post/5662</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/5662</guid><dc:creator><![CDATA[sander]]></dc:creator><pubDate>Thu, 17 Nov 2022 12:56:38 GMT</pubDate></item><item><title><![CDATA[Reply to Migrating from mysql to postgresql on Fri, 02 Sep 2022 17:16:57 GMT]]></title><description><![CDATA[<p dir="auto">Just for clarity, this code was provided by a community member and has not been tested nor will it be supported by the FusionAuth team. It is occasionally shared by the FusionAuth team as a service to folks running MySQL, but the expectation is you'll review, test and support this code yourself should you find a need for it.</p>
]]></description><link>https://fusionauth.io/community/forum/post/5441</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/5441</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Fri, 02 Sep 2022 17:16:57 GMT</pubDate></item><item><title><![CDATA[Reply to Migrating from mysql to postgresql on Wed, 28 Apr 2021 14:52:42 GMT]]></title><description><![CDATA[<p dir="auto">Community member Francesco Latini wrote a github gist for exactly this purpose:</p>
<p dir="auto">The gist is here: <a href="https://gist.github.com/checco/c752b15671b9f846ce40bb0e5bf810b0" rel="nofollow ugc">https://gist.github.com/checco/c752b15671b9f846ce40bb0e5bf810b0</a></p>
<p dir="auto">but here are the contents:</p>
<pre><code># pgloader help
docker run --rm --name pgloader dimitri/pgloader:latest pgloader --help

# run pgloader
docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification --verbose --debug \
"mysql://odyssey-auth:${mysql_password}@${digitalocean_mysql_host}:25060/odyssey-auth"
"postgresql://odyssey-staging-auth:${postgres_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" 

# first error, because of mysql_native_password on MySQL 8
ERROR mysql: Failed to connect to mysql at "odyssey-staging-do-user-4848868-0.b.db.ondigitalocean.com" (port 25060) 
as user "odyssey-auth": Condition QMYND:MYSQL-UNSUPPORTED-AUTHENTICATION was signalled.

# create a dump from MySQL 8, because we have to do it on MySQL 5.7
# as we don't have any kind of control on the MySQL conf file on DigitalOcean
mysqldump -u odyssey-auth -p${mysql_password} -h ${digitalocean_mysql_host} -P 25060 odyssey-auth &gt; data/odyssey-staging-auth.sql

# restore dump into a mysql 5.7 docker container
docker run --name staging-mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -d mysql:5.7
docker exec -i staging-mysql sh -c 'exec echo "CREATE DATABASE IF NOT EXISTS \`odyssey-staging-auth\`;" | mysql -uroot -p"password"'
docker exec -i staging-mysql sh -c 'exec echo "SHOW DATABASES;" | mysql -uroot -p"password"'
docker exec -i staging-mysql sh -c 'exec mysql -uroot -p"password" odyssey-staging-auth' &lt; data/odyssey-staging-auth.sql
docker exec -i staging-mysql sh -c 'exec echo "SHOW TABLES;" | mysql -uroot -p"password" odyssey-staging-auth'

# run again pgloader from the local mysql to the DigitalOcean instance 
docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification --verbose --debug \
"mysql://root:${mysql_password}@192.168.0.101:3306/odyssey-staging-auth" \
"postgresql://doadmin:${postgresql_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require"

# you'll have another error about the unkown collation
ERROR 1273 (HY000) at line 77: Unknown collation: 'utf8mb4_0900_ai_ci'
# Replace utf8mb4_0900_ai_ci collation with utf8mb4_bin
# (an example with VIM)
:%s/utf8mb4_0900_ai_ci/utf8mb4_bin/g

# run again pgloader and this time it should work but when you try to startup FusionAuth, you'll have the error:
# ERROR: operator does not exist: bytea = uuid
# run pgloader again introducing the cast to change the type from binary to uuid
# because, by default, pgloader casts all the records with binary type to bytea
# here the docs: https://pgloader.readthedocs.io/en/latest/ref/mysql.html#default-mysql-casting-rules
docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification \
-L staging-migration.log --verbose --debug \
--cast "type binary to uuid drop typemod using sql-server-uniqueidentifier-to-uuid" \
"mysql://root:${mysql_password}@192.168.0.101:3306/odyssey-staging-auth" \
"postgresql://doadmin:${postgres_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require"

# check if the first command has been already executed by pgloader
# it should be the last one before the summary and it's really important
ALTER DATABASE "odyssey-staging-auth" SET search_path TO public, "odyssey-staging-auth";

# alter all the grants to the right user
ALTER DATABASE "odyssey-staging-auth" OWNER TO "odyssey-staging-auth";
ALTER SCHEMA "odyssey-staging-auth" OWNER TO "odyssey-staging-auth";
REASSIGN OWNED BY doadmin TO "odyssey-staging-auth";
</code></pre>
]]></description><link>https://fusionauth.io/community/forum/post/2901</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/2901</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Wed, 28 Apr 2021 14:52:42 GMT</pubDate></item></channel></rss>