VS CodeがPostgresのIDEに！
引用元：https://news.ycombinator.com/item?id=44073588
俺、pgstrapってnpm作ったんだけど、これVS CodeでPostgres見れるの超便利！DB構造をファイル化してLLMとかコードレビューに使えるんだ。Railsのschema.rbみたいなね。エディタ側でDB認識させるか、コードに入れるか迷うけど、VS Codeなら開発での標準になるかもね。
え、分かんないんだけどさ。DBスキーマとそこに至るまでのマイグレーションをバージョン管理に入れるのって、Webフレームワークなら普通じゃないの？
それって社員が＜10人で顧客が＜3社とかまでしか通用しない話だよ。それ以上になると、RailsアプリだけがDBの持ち主じゃなくなるからね。
複数のアプリで共通のDBスキーマいじることあるの？それどうやって全部のアプリで同期保つの？
俺は読み取り専用ログインできるMCPサーバー使ってるよ（copilotかclineと一緒に）。
まあ普通はどれか一つが”メイン”になるんだけど、個人的には”やめとけ”って言うかな。君も気づいてるだろうけど、色々問題あるからさ。ここで言う”やめとけ”ってのは、複数のアプリが同じDBスキーマを使うなってことね。
”やめとけ”ってのは正解だよ。他の人も言ってるけど、俺が働いた大手SaaS企業の多くは、アプリごとにDB持たせてた。何か必要ならAPIかETLを使うんだ。
それは絶対間違ってるね。むしろ完全に逆の答えだよ。サービスにすると遅いし、色々制限されるし、トランザクションみたいな実際のDBMSのメリットも得られない。それに余計な依存関係や障害点も増えるんだ。
＞これはサービス使うかどうかの議論じゃなく、サービスがDBとやり取りする場合の話ね。複数アプリがDB直接触ると悪夢になりがち。互いのコードをDB内部から切り離すためにも、サービス間で契約決めてやり取りする方が断然良いってこと。
＞前のコメントの「サービスで隔てる」ってやつね。それだと依存関係が移っただけで、スキーマ変更時にサービス更新も必要になって手間が増える。トランザクションとか性能、柔軟性も失うし、負荷も失敗も増える。良いとこないよ。
他のサービスにアクセスさせるのがAPIの役割だよね。Jeff Bezosが昔言ってたけど[1]、そうしない奴はクビだって。俺もそう思うよ。[1] https://news.ycombinator.com/item?id=18916406
それってさ、LLMにDBの正真のデータ源に直接アクセスさせるより、絶対悪い方法だよ。DBとLLMの間で余計なやり取りが増えるし、コード生成始まる前にツール呼び出しを会話に挟むことになるからね。それに、有名なPostgresのMCP実装はPostgresの型とかマテリアライズドビューを含んでないんだ。Zed.devのMCPサーバーとかも、その移植版みたいで同じ問題を抱えてるみたいだよ。
ちょっと分かんないな。複数のアプリが同じDBを管理したりアクセスしたりするって話だったよね。どう考えても、スキーマを更新したらアプリも更新しなきゃいけないじゃん。むしろ、サービス指向のアプローチなら、APIのバージョン管理とか互換性ロジックを1箇所に書くことで影響を隔離できる可能性だってあるのに。
ちょっと興味あるんだけどさ、結果のデータはLLMが使うの？それともただSQLを生成して、実行して、結果を返すだけ？
それよりさ、DB使ってるもののバージョン管理に、DBのスキーマ全体がリポジトリに含まれてるのがもっと謎なんだけど。
そういうことよくあるけど、スキーマが言語固有のORM向けに書かれてる場合もあるんだよね。そのコードがプラグインとかフィーチャーフラグを持ってて、実行時まで具体的なSQLスキーマが分かんないってこともある。シードデータとかマイグレーションも同じ。だから、実際のDB接続と比べて、この形式がツールとか発見にどれだけ役に立つかはユースケース次第だね。
＞ スキーマ更新はアプリ更新を伴う
1. DB → App = 2回の更新、スキーマとアプリ
2. DB → Service → App = 3回の更新、スキーマとサービスとアプリ
どちらの場合も、当然DBは変わるよね。アプリも変わる。2番目のケースでは、サービスも更新しなきゃいけないってこと。
まともなORMなら、migrationファイルにはSQLを使うだろうね。
プロジェクトのPMだけどね。クエリの結果は基本的にはLLMは使わないよ。ただエージェントモードだと、クエリ計画中にエージェントがデータのサンプルを取得してクエリの精度を上げることはある。例えば、ディメンションテーブルからユニークな値を取ってきて、自然言語のステートメントからフィルタ条件を解決するとかだね。
すごく実用的なツールみたいだね、シェアしてくれてありがとう！興味あるんだけどさ、triggersとかstore proceduresとかも出力するの？多くのツールはテーブルとかカラム、インデックスを定義したところで止まってるみたいだけど、DBの他の機能をもっと活用するためのツールがあると嬉しいな。
いや、DB変更はそんなに分かりやすくないって。だって、そのスキーマに依存してるチームとはあんま話さないし、そもそもそんなチームがいることすら知らないかもじゃん。API契約でも同じだけど、API変更の文化はもっと「伝えなきゃいけないこと」って理解されてて、プロセスもちゃんと決まってるんだよね。
＞いや、DB変更はそんなに分かりやすくない…って？
君が言ったこと、全部サービスやAPI契約にもそっくり当てはまるじゃん。何も解決してないよ。
＞API変更の文化はもっと「伝えなきゃいけないこと」って理解されてて…
それはただの作り話だよ。毎日何千件もインシデント起きてるじゃん、誰かが全関係者に伝えずAPI変えちゃってさ。”サービスの方がデータベースより優れてるのは、サービスオーナーの方がデータベースオーナーより変更伝えるのが上手いから”とか、全然説得力ない主張だよ。
ひどい技術ソリューション導入する前に、コミュニケーションの問題を直す努力をした方がいいと思うけどね。
そうそう！基本的には pg_dump を実行して、その出力をいろんなファイルに分類してくれるんだ。だから網羅的だと思うよ。確か、functions/function_name.sql とか misc.sql とか triggers.sql とか、そんな感じであったはず。
どうも。こういうツールが本番DBに繋がるの、ちょっと心配なんだよね。。特にLLMエンドポイントを簡単に切り替えられること考えると、そのデータがどこに行って、どう保持されて、文脈とかさ、プライバシー的にちょっと悪夢になりそうだし。。
アプリのDBスキーマは、実質的にコードと言えるくらい密結合してるし、マイグレーションも多分チェックインされてるはず。だから、DBスキーマが時間とともにどう変わるか—おそらくそのスキーマを使うクエリと一緒に—見れるようになるんだよ。
カノニカルな状態ってのは、本番DBにあるものだよ。バージョン管理に入ってるのは、それを再構築できるといいなって感じだね、ただしデータを再投入できる可能性は極めて低いっていう明らかな注意点付きでさ。
全くもって正当な懸念だね。うちの拡張機能は Github Copilot 経由でLLMに繋がってるんだ。Github Copilot は Microsoft の製品で、いろんなエンタープライズプランを提供してるから、情シスがどんなデータを何に使えるか承認できるんだよ。これで企業の要求へのコンプライアンスに向けて明確な道筋ができるわけ。
そうした方がずっといいのは同意するけど、たぶん一番大きいフレームワークって Django とか Rails じゃない？で、それらは（そう）しないんだよね。
500ミリ秒未満のラウンドトリップ（たぶん50トークン分くらい）が、もしかしたら役立つかもしれないからって、何千トークンも余計にプロンプトに含めるより悪いって考えがよく分からないんだよね。コンテキスト疲れは言うまでもないし。
もしうまく設計されてれば—メモリで生成を中断して、＜function_result＞を挿入する感じで、生成を再開したりディスクからキャッシュ取ってきたりせず—ラウンドトリップ/ツール呼び出しの方が優れてるんだよ（待ち時間で50トークン相当＋function_resultトークン分だけ）。
＞他のサービスへのアクセス提供こそAPIの役目だろ。
そうそう、そしてデータベースだって、複数の消費者向けに、すごく実績があって堅牢なセキュリティと権限モデルを備えた、広範なAPIを公開してるんだよ。
もっとコメントを表示（1）
彼がそうしたのはビジネス的な理由だよ。スタックのどんな部分でも外部顧客に公開サービスとして提供できるようにしたかったんだ。
逆に、内部サービスを公開サービスと競合させるためでもあったんだって。
でも、これってAWSみたいなものを作る場合にだけ有効な話だよね。みんながみんなそうするわけじゃない。
リレーショナルデータベースにきめ細かい権限システムがあるのには理由があるんだよ。
うわーこれすごいね！
SQL ServerじゃなくてPostgresのためにここまで力を入れたってのはかなり驚きだよ。
Postgresの方が需要がずっと高いんだろうね。
Microsoftはここ10～15年くらいオープンソースにかなり本気を出してきてるみたいだね。
ユーザーの視点から見るとほとんどみんなメリットを受けてるんじゃないかな。
ビジネスの視点から見ると無償の協力者やコミュニティからの良い評判を得られるってわけだ。
＞ここ10～15年くらいオープンソースにかなり本気を出してきてるみたいだね
VS CodeにはたくさんのMicrosoft製のクローズドソース拡張機能があってこれはオープンソース版のVS Codeとは法的に一緒に使えないんだよね。
だから彼らが”完全に本気を出してる”とは言えないと思うな。
せいぜい腰まで浸かってるって感じかな。
クローズド拡張機能の状況からオープンソースの部分がなんか不誠実に見えちゃうんだよね。
なんか無料プランは10ユーザーまででそれ以降はめっちゃ高くなるみたいな状況に似てる。
目的は無料プランじゃなくて最終的に本当においしいところへ誘導するための広告手段って感じ。
MS SQL serverはレガシーシステムだよ。
技術的な理由で他に選択肢がない場合を除いて新しいデータベースをSQL serverで作るビジネスなんてないと思うな。
彼らすでにSQL Server Management Studio[1]を持ってるじゃん。
あれってこれと似たような範囲をカバーしてるみたいだけど？
多分いつかSSMSをVS Codeに移行させたいと思ってるんじゃないかな。
だから新しい分野のPostgreSQLを扱うことでそれを試してるって考えるのは理にかなってると思うんだ。
[1]: https://learn.microsoft.com/en-us/ssms/sql-server-management…
君は考えがごちゃ混ぜになってるよ。
Microsoftが”誠実”じゃないのは彼らが単なるビジネスをやってるからだよ。お金を稼ぐっていうビジネスがやることそのもの。
彼らは利他的とか原則に従ってるとかそういうのを目指してるわけじゃない。ただビジネスをしてるだけなんだ。
でも個人的にはTypeScriptとVS Codeを自由に使えてこの取引からは恩恵を受けてるけどね。
僕はすべてのビジネスが”ただのビジネス”だとは思わないな。
タバコ会社とかPurdue Pharmaみたいな極端な例もあればMozilla CorporationとかValve（議論の余地はあるけど僕は彼らはクールだと思う）みたいな反対側の例もある。
もちろん大きな会社は実際にはたくさんの異なる存在が集まってるみたいなものだけどね。
Microsoftには長い間不誠実な行動の歴史があるんだ。
中にはかなり洗練されてて長期的な視点に基づいたものもある。
だから彼らを一般的に信頼するのはすごく難しいんだよ。
そもそもなんでVS Codeの一部はFOSSじゃないんだろう？
いや目的が違うんだよ。
VS Code拡張機能と以前のADSは開発向けだけどSSMSはサーバーとデータベースの管理向けなんだ。
僕はSSMSをすごくよく使うし必要なことは全部そこでできるんだ。
VS Codeはかなり使うけどMS SQL用のVS Code拡張機能はインストールしてても使ってないんだよ。
これは僕がDBAチームのバックアップや監督もしてるからでDBAの仕事に関わってるからなんだ。
＞ Microsoftが不誠実だって言うけど、20年前の独禁法裁判以外に最近の具体的な例ってあるの？他の人の借り物意見をただ繰り返してるだけじゃない？って思うんだよね。自分で体験したことじゃなくて、読んだことだけでMicrosoftのこと悪く言う人が多い気がする。
SQL Serverって技術的にはめちゃくちゃ良いんだよ。でも、使うにはすごいお金がかかる。エンタープライズ向けなら、それだけの価値があるかもしれないけどね。
これって、MSSQLのツールがAzure Data Studioでメンテされてて、良い状態だったからじゃないかな？ADSはもう終わる方向だし、VS CodeのPostgres拡張見たら6年も更新されてなかったみたい。だから、ADSから移行先がなくて、ずっとADS使い続けてたんだよね。
VSCodeって、オープンソースのエディターで、Pythonとかの有名言語の拡張もOSSだよ！って宣伝してたじゃん。なのに、人気出てvscodiumみたいなフォークが増えてきたら、Microsoftは閉鎖的にしたんだよな。今じゃPython拡張はクローズドソースで、VSCodeのフォークじゃ使えないようにした。これって完全に”ベイトアンドスイッチ”だろ。
俺も同じ意見だよ。SSMSはSQL ServerのVSツールよりずっと良いし、Transact-SQLのサポートとかも含めてね。
Microsoftはpostgresのプラグインを、Microsoftの社員じゃないと貢献できないように作っちゃったんだよな。Azure Data Studioの他の部分もそうだけど、彼らが管理レベルを高く保とうとしたせいで、誰も一緒に開発しようって思わなかったんだ。
Microsoftのデベロッパーアドボケイトだけど、SQL ServerチームもPostgreSQLチームも拡張機能の改善にめちゃくちゃ力入れてるよ！
使いやすさの調査とか、バグ潰しにも参加したんだけど、どっちのチームも開発者にツールを楽しんでほしいってすごく思ってるから、使ってみて欲しい機能とか、不満な点とか、どんどんフィードバック送ってね！
SQL Server拡張のニュースはCarlos Robles、PostgreSQL拡張のニュースはJoshua Johnsonをフォローすると良いよ！
＞ VSCodeの宣伝で「ベイトアンドスイッチ」だって言うけど、そんな宣伝どこにあったの？1.0リリースのアナウンスブログ読んだけど、見当たらないんだけど。
プロジェクトが成長して成熟していく上で、ちゃんとルールを決めるのは当たり前じゃん。プラグインマーケットプレイスをMSの独自のものにするのも、全然理にかなってると思うよ。
MicrosoftはVSCodeにめちゃくちゃ貢献してるんだから、プラグプレイスとかPython拡張をクローズドにする権利くらいあるでしょ。
なんでみんな、VSCodeにちょっと関連してるものなら全部”just because”でタダで使えるのが当たり前、とか、Microsoftが他の億万長者の会社のビジネスを補助する義務がある、とか思うわけ？
「ベイトアンドスイッチ」だって言うけど、どこが？クローズドソースのプラグイン出しただけなのに、最高の根拠がそれなら、これはまた別の”借り物の意見”として分類させてもらうよ。
個人的には、昔のSQL Query AnalyzerとかProfilerが好きだったなぁ。今でもあれが一番使いやすかったSQL IDEだと思うんだよね。
この件（と他のMicrosoftのやり方）、「”偽のオープンソース”」って呼んだんだよね。コメントには賛否両論すっごくあってさ、みんなが同意してるわけじゃないのは明らか。オレ的には、Microsoftはオープンソースのいい感じとPRだけが欲しいだけで、ほんとはオープンソースになりたくないんだと思う。だからこの分野で今でも多くの人が彼らを信用してないんだよ。
SQL ServerはOracleみたいに、技術的には超すごいよ。長いことPostgresより先を行ってたし、今でもそうだって言う人も結構いるね。みんながあんまり使わないのは、タダじゃないし全然安くないからさ。
彼らのvscodeへの貢献はすごいけど、Python拡張を最初はOSSにして人気が出たらプロプライエタリにしたのはどうなの？最初に意図を明確にすべきだったんじゃない？人気が出てからOSSだったものをクローズドにしたのは”おとり商法”だろ。Pythonスタック全体をOSSで出して、その後プロプライエタリ版を出してOSS版を非推奨にし、他のフォークが使えないようにしたんだから。
これって多くのツールに当てはまるみたいだね。Microsoftの公式Pythonライブラリ使ってるんだけど、リポジトリはGitHubで公開されてるのに、CIとか裏側の連携は全部Microsoftの内部で非公開。だから外部からは全然参加できないんだ。しかも、前にそのツールをサポートしてたチームがいなくなっちゃったから、今は誰もメンテできない状態だよ。
8年前くらいの話だけどさ、Microsoftがドイツのオフィスをミュンヘンに移して、その代わりにミュンヘン市がLinuxへの移行を止めるように仕向けたんだ。別に嘘ついてるわけじゃないけど、応援してた競争相手を潰すためのパワープレイだよね。僕がいた頃のMicrosoftは、誰も歯止めかけられられなかった時期はマジでひどい奴だったよ。事実は動かないんだから。
そうそう、特に古いアプリが恋しいね。あれは本当によくデザインされてて、めっちゃサクサク動いたんだよ。SSMSが始まった頃は、俺のPCだとめちゃくちゃ遅くて重かったなあ。その頃にPostgresに切り替えたから、もう20年もブランクがあるけど。
だってさ、巨大企業にバックアップされてるんだからそうあるべきでしょ。それにPostgresみたいなオープンソースのDBから学んで、彼らのシステムをもっと良くできるんだし。
キャリアの始めはMSSQL、今はPgなんだ。MSSQLはデータベースエンジンとして本当に、本当に優秀だよ。でもびっくりするほど高いんだ。使ったことない人は、どれだけ優秀か知らないだろうね。
＞ It would have been fine if MS had started with their Python extension being proprietary
それ、全然違うってば。Pyrightは最初からオープンソースで今もそう。PylanceはPyrightの上に作られたけど、ずっとオープンソースじゃないんだよ。別に約束とかしてないしね。オープンソースのPython Language ServerをやめてPylanceを使うようにしたのだって、全然ありな判断でしょ。コミュニティがメンテナンス続けるのは自由だったけどね。俺の知ってるほとんどの人はPylanceに頼り続けてるけどさ。
＞ Instead, they lured folks in
そう言うのは勝手だけど、本当じゃないってば。
＞ Instead, they lured folks in （no small part due to open source）, and once it became popular, they started turning the screws and making things proprietary and locking it down.
MicrosoftはVS Code関連でオープンソースにしたものをひっこめたことは一度もないよ。全部オープンソースじゃないからって悪者にするのは無理があるってば。
＞ I don’t think it is unreasonable to ask someone to make their intentions known up front do you？
伝えてるしね。Microsoftが不誠実なやり方をした実際の例を一つでも挙げてみてよ。99%がFOSSなのに、一部をプロプライエタリにしてるって話じゃなくてさ。
＞ Vscodium is an entirely free and open source fork
MicrosoftとVS CodeチームはVscodiumのこと考えて長期的な判断はしてないよ。でも、WindsurfとかCursorのことは心配してるかもね。特にCursorは（数十億ドルの会社なのに）MicrosoftのTOSに違反してたし。
Microsoftは10年以上もVS Codeの公式プラグインエコシステムに投資して、良い管理者であろうとしてきたんだ。それを自分たちのも
これってビジネス以外の何ものなの？地方自治体が雇用とかSALTを生み出す企業に譲歩するのなんて当たり前で、Microsoftが特別ってわけじゃないよ。
＞ One of these is that Microsoft was a pretty bad actor when nobody reigned them in, and I was around at the time.
俺もそうだよ（当時はRedmondで働いてた）。彼らのやり方は、今AppleやGoogleがやってることより悪くなかったってば。独占禁止法訴訟自体、90%がお芝居だったし、Microsoftはお目玉食らっただけで済んだのに、なぜか世間では実際よりずっと大変だったことになってる。これは「M$悪い」っていうバイアスを強めるからだろうね。こういうコメントは、自分で調べた意見じゃなくて「借りてきた」意見としか思えないし、Microsoftのこととなると、みんな自分で考えずに人の意見を借りてきてるんだなって改めて確信したよ。
そう、Microsoftは25年以上前にひどいことをいくつかやって、その報いも受けた。でも、2025年の今、時価総額で世界最大の会社になっても、他の企業と同じように活動してるよ。いつまでもこのカードを切り札みたいに出し続けるのはもう無理だってば。
＞＞ all without ever leaving your favorite code editor
それ、Neovimにどうやってインストールするの？LSPはある？それともこれってMicrosoft独自の囲い込み？Copilot連携なしで、他の競合製品と比べてどれだけ良いのかな。
俺は今DBeaver CEを使ってるよ。これならSQLiteも含めて必要なことは全部できるしね。
もっとコメントを表示（2）
営利企業が「みんなのためにXを民主化！」って書くときは、「金払える人で、禁輸されてない人向け」って意味。‟シンプルに”って書くときは、「うちの囲い込みにハマれ」って意味。「お気に入りのX！」って書くときは、「あんたに売りつけてる製品」って意味。そんな感じだよ。
こういうビジネス用語辞典でプレスリリースを読み始めると、すぐにタブを閉じて次に進むのがすごく楽になるよ。
DuckDBのためにも、俺はDBeaver CEをプロとして過去9年間使ってるよ。Python開発してる時も、すぐに何か必要な時はJupySQLをJupyterで使うし、それはVS CodeでもJupyterプラグイン経由で動くよ。
絶対これチェックするつもり。キャリアを主にSQL ServerとSSMSで始めたから、SSMSが手袋みたいに脳にフィットするんだよね。Postgresに移ってから多分10年くらいになるけど、pgadminとかdbeaverとかdatagripみたいな典型的な選択肢にずっと不満だったんだ。Postgres自体は最高なんだけど（誤解しないで、SQL Serverも素晴らしいし、金がかかるだけ）、そのDBMSツールのエコシステムについて、なんでコミュニティでもっと騒ぎにならないのかずっと理解できなかった。
Datagripが断トツで一番すごいユニバーサルデータベースツールだって分かったよ。全部試したと思うけど、どれもIDEデザイナーじゃなくてデータベース作ってる人が作った感じなんだよね。機能の深さ、拡張性、改善ペース—すごく満足してる顧客だよ。
オープンソースを悪く言いたくないけど、pgadminとかdbeaverは全然同じレベルじゃない。Oracleで仕事してるけど、Datagripにマジで救われた。
Datagripで特に気に入ってる機能って、DBeaverにはないものなの？
Datagrip使う前はDBeaver（コミュニティ版）使ってたけど、全体的にはDatagripに軍配が上がるかな。Jetbrainsの全製品パック持ってなかったら試してなかったと思う。DBeaverも素晴らしい、誤解しないでくれ。でも、Datagripの方が全体的に洗練されてて、設定とかUIがもっと直感的に感じるんだ。
もっと洗練されたUIだね。グラフビューアはテーブルに色つけたり関連テーブルを表示したりして、見やすいと思うよ。内観とかコード整形もちょっと良い感じ。リファクタリングもしやすいし、DBeaverでEclipseプラグインを使うよりIdeaVimも簡単に動かせるんだ。
個人的な経験だと、DataGripの方がDBeaverよりすぐに使い始められてIDEの機能も充実してるけど、DBeaverもかなり優秀だよ。例えば、DataGripではAccessと連携できなかったけど、DBeaverはあのゴミみたいなAccessでも結構使えるんだ。しかも無料だしね。どっちも良いツールだよ。
DatagripはJetbrains製品のデザインが好きって人も嫌いな人もいるよ。30日トライアルで1日試せば合うか分かるんじゃないかな。どんなDBでもサポートしてるし、IDEベースだからプロジェクトやスクリプト管理が楽なのは開発者にとってすごく便利。
ただ年間99ドルの価値があるかは微妙かも。僕はJetbrainsのパックで使ってるから実質タダだけどね。Jetbrainsユーザーじゃないなら値段と価値を考えてみて。
Datagripだと、JetBrainsのIDEの良いところ全部使えるんだよね。すごいカスタマイズ性、たくさんのプラグイン（IdeaVimとかGitHub Copilotとかね）、ドキュメントも豊富だし。それに、数えきれないくらいのDbエンジンをサポートしてるのもいいね。まだサポートされてないDbは見たことないかも。唯一、Redisのサポートは中途半端だったけど、あれは厳密にはDbじゃないしね。一番大事なのは、PgAdminみたいにUIがもっさりしてないこと。全部が洗練されてて、多くても1、2クリックで済む感じだよ。
どんな新しいイケてるツールが出てきても、俺をDatagripから引き離すのは無理だろうな。長年たくさんのdatabase admin UIsを使ってきたけど、Datagripが断トツで一番すごいよ。
これは主観的な意見だけど、インターフェースは良い感じだよ。特に他のjetbrain製品に慣れてるならね。しばらくpgAdminは使ってないけど、autocompleteが使いにくくて正直かなり悪かった覚えがあるな。会社の余ってたDatagrip licencesを使ってみたら、notepadからIDEに移行したみたいで感動したよ。あれ以来、もう他のツールには戻れないね。
前のコメントのDBAの話、同意だよ。ツールは重要だけど、開発者向けのツールは珍しいね。多くのツールは管理寄りで、開発ワークフローを理解してるツールが少ないんだ。昔Oracle向けにあったPL/SQL Developerみたいな開発中心のツールがPostgreSQL向けにはまだ見つからないな。
今はDataGripでなんとかやってる。DataGripはtext editorよりはマシで、必要な機能がギリギリ揃ってる感じだよ。
前のコメントのDBAの話を受けて、自身のDB開発経験（Hibernateの失敗談、自作ツールの話）を展開している。記事のテーマ（VS CodeのIDE化）やコメントの主流（DataGrip/DBeaverの比較）からは少し外れるが、DB開発のワークフローやツールに関する深い洞察を提供している。関連性は中程度だが、内容は面白い。中高得点。 -＞ 65点。
ふーん、面白いね。俺もDatagripを何年か使ってたけど、今はDBeaverを使ってるんだ（もうJB subscriptionに入ってないからね）。Datagripは賢いintellisenseとかあって、前も今も多分すごく強力だと思うよ。今はDBeaverを使ってるけど、これもすごく安定してるね。まあ、一日中使ってるわけじゃないけど、必要な時にはちゃんと仕事してくれるよ。
俺にとってJetBrainsがVSCodeより圧倒的に良かったのは、すごくきれいな組み込みのデータベースツールだったんだよ。
データベースツールは別に（DataGripとして）実行することもできるよ。俺はそうしてる。
毎年くらいVSCodeに戻ろうとしてるんだけど、JetBrainsのgitとデータベース連携がマジで良すぎて乗り換えられないんだよね。
VS Codeのgit連携は悪くないと思うけど、その実装方法がすごくMicrosoftっぽいんだよね。UIがプロフェッショナルなVisual StudioのUIにそっくりで、それが良いか悪いかは完全に個人の好みだね。俺はJB’sのgit連携の方がずっと好きだけど、UIが全然違うからってだけでダメだとは言わないけどさ。
Posticoがいつも俺のPostgresを操作する定番ツールなんだ。Posticoユーザーでこれを試した人いるか気になるな。
めっちゃMac向けだよね、それにIntelliJの組み込みDBエディタの方が全然機能が多いと思うな。
すごくMacのUXに準拠してるのが、PosticoをPostgresの簡単な作業の99%で使うのが好きな理由なんだ。
Posticoを10年以上使ってるよ。これ試してみるつもり。node-pgを使う時にCopilotがスキーマを認識し始めてくれるといいんだけどな。
ローンチおめでとう！俺がMicrosoftで最初にデモしたんだよ。その時の動画はこれ：https://www.youtube.com/watch?v=k6Vm2hakkV4＜br＞デモした全機能はこのリポジトリで試せるよ：https://github.com/Azure-Samples/postgresql-extension-playgr…＜br＞何かあったらここで報告してね：https://github.com/microsoft/vscode-pgsql/issues
