前提

AzureのPostgresを検討している人。自分でサーバーを立てるのではなく、Azure Database for PostgreSQLの使用を検討している人向け。個人的に、備忘録も兼ねている（※1）。

※1 記憶を頼りに書いている内容なので、現状は異なるかもしれません。その点ご了承ください。

■OSがwindows

OSなんてなんでもいいだろ？なんてことはない。個人のレベルで使用するのであれば、使いやすければなんでもいいと思うが、さすがに業務用のDBともなると可能な限り強固なサーバーを準備したいのが当たり前。年配のエンジニアの方であれば同意いただけると思うが、経験上Windowsサーバーはどうしても不安が残る。懸念事項は少しでも減らしたいので、意見を求められることがあれば必ずLinuxのサーバーを推していた。

さて、ではWindowsのPostgreSQLとLinuxではどんな違いがあるんだろうか？

アプリケーションサイドで早々に見つかったのが、LinuxとWindowsではOrderByの結果が違うということだった。

まさかと思ってpsqlで照合順を確認してみると、AzureのPostgresは Japanese_Japan.932 になっている。ここでぐぬぬっとなった。Microsoft提供のAzureだけあって、OSはWindowsを使用しているらしい。Postgresのバージョンをそろえておけばいいだろ、くらいの軽い気持ちでUbuntuで開発環境を作ってしまうというミスをしてしまった。

UTF-8かEUC-JPだと思っていたので、慣れからくる思い込みは手痛い、心底そう思ったミスだった。

以下は注意レベルでいいので短めに流す。

■拡張パッケージが限定される

自前のサーバーとかVMだったら、気軽にとまではいかないもののパッケージの検証ができる。だが、AzureのPostgresは使用できるパッケージに制限がある。特にマルチバイト検索の拡張パッケージは、現時点では存在しない。まぁ、サービスを提供する側が信頼できるパッケージがそもそもないという判断なのだから仕方がないのだが。日本語検索機能をもつアプリを提供する場合は、注意が必要だ。

■柔軟なパラメータ設定ができない

クラウドサービスだから致し方ない面もあるが、やはり自前のサーバーに比べると設定項目が限られる。GUIからの設定のみで、postgresql.confが直接編集できるわけではない。Azure提供のデフォルト値が設定されているので、logがONになっているとか、運用面からみると微妙な設定になっている個所もあるので、きちんと整理しておく必要があった。

■DB間連携が微妙

postgres_fdwを試験していての体感だが、これが遅い。とにかく遅くて使い物にならなかった。これもまた、クラウドサービスなのだから仕方ない話。同じデータセンター内だとしても、一緒のラックに入っている保障などあるわけがない。物理的な経路が指定できるわけではないのだから、早いこともあるが遅いこともある。この不安定さは業務システムとしては致命的な欠陥となる。レプリカ作ったら遅くなりました、なんてことになったら目も当てられない。

■lc_timeが日本時間ではない

TimeZoneの設定はGUIで行えるが、lc_timeはSQLで変更する必要がある。DB作成後に、alter database dbname set lc_time to ‘japanese_Japan.932’; とする。もしかしたらGUIで変更できるのかもしれないが、自分には見つけることができなかった。。

■そのほか

とりあえず、azure_pg_admin権限を与えておけば問題ないと思う。
稼働率は当然100%ではない。事前に通知があるとは言うが、年に何度かはサーバーが稼働していないタイミングがあるとのことだった。実運用に入った段階で、pgbouncerかpgpoolの導入は検討しておけばよかったと感じた。レプリカがあればなんとかなると思っていたが、そこまで甘くはなかったので。。