発端はPlanetScale無料枠終了。Neonに移行するか悩み取り敢えずやってみる。
で、PlanetScaleはMySQL系でNeonはPostgresなので簡単には行かない。

config.loadファイルを作って以下のものを用意

load database
  from mysql://xxxxxxx:pscale_pw_xxxxxxx@aws.connect.psdb.cloud/mydb?sslmode=require
  into postgresql://xxxx:endpoint=ep-patient-xxxx;xxxx@ep-patient-xxxx.ap-southeast-1.aws.neon.tech/mydb?sslmode=require
  with quote identifiers
  alter schema 'mydb' rename to 'public';

以下を実行（事前にbrew install postgresql, brew install pgloader）

pgloader config.load

quote identifiers

MySQLのテーブルやカラム名に大文字を使っている場合、このquote identifiersがないと移行後全て小文字になる。

alter schema 'mydb' rename to 'public'

これがないと移行後のschemaがpublicではなくmydbとして作られてしまう。

Teruhisa - T6ADEV 2ヶ月前

詳細はこちらを参照

Postgresといえば、そーだいさん

Teruhisa - T6ADEV 2ヶ月前

試しにこれをするきっかけとなったプロジェクトのDB先を移行後のNeonにしてみた。
アプリ画面を開いてみただけだけど、動いた。動いた・・・（逆に不安）

Prismaでschema定義してて細々Postgres用に変更する必要もあるだろうと思っていたけど。

Teruhisa - T6ADEV 2ヶ月前

pgloader後、prisma migrate dev してみた所、差分が出てきてAll data will be lost.がでちゃった。

Teruhisa - T6ADEV 2ヶ月前

prismaコマンドだけでゴニョゴニョするのは無理がありそう。
素直にデータだけコピーするほうがいいか・・・

Teruhisa - T6ADEV 2ヶ月前に更新

背景：PlanetScale(MySQL)からNeon(Postgres)への変更。DBはprismaで管理。サービスは動かして数名のユーザーが利用中。移行すべきテーブルのデータは”少ない”（実験的なプロダクトなので重要なもの以外は消えても問題ない）。ダウンタイムはあっても問題ない。

案：

pgloaderでNeon（Postgres）へデータをコピー（これは正式な移行としてではない）(pgloaderでmysqlからの変換を任せる)
Neonに対してpg_dumpで必要なデータのみをSQL文でバックアップ
1.でNeonにDBが出来たが、DBごと全て削除
schema.prismaをNeon用に変更（provider = "postgresql"へ変更, relationMode = "prisma"削除, planetscaleで必要だった@@index()は不要なので削除）
npx prisma migrate dev --name init
2.のSQL文を使ってデータを流し込む (例psql "postgresql://xxx:xxx@ep-patient-xxx.ap-southeast-1.aws.neon.tech/xxx?sslmode=require" -f ./backup.sql)
※2で得られたbackup.sqlの中身は必要なsql文を精査する。外部キーとの兼ね合いも考えて主キーとなるinsert文を先に実行させる

pg_dump --column-inserts -Fp YOUR_DBNAME > backup.sql

--column-inserts　：列名指定のINSERTコマンドでデータをダンプ
-F, --format=c|d|t|p ：　出力ファイルの形式(custom, directory, tar, plain text(デフォルト))

このスクラップは2ヶ月前にクローズされました