Django生誕20周年！多くの開発者のキャリアを築いたPythonフレームワーク
引用元：https://news.ycombinator.com/item?id=44552500
俺のキャリアは全部Djangoのおかげ！学部生の頃、セキュリティとか気にせずDjangoでウェブサイト作ってたのが始まり。2009年にはDjangoの知識でMLの研究室に採用されて、PhD学生がMySQLとDjango ORMで作ったごちゃごちゃを整理したよ。その後、AI企業を立ち上げたり、VC fundを共同設立したり、色々あったけど、全部Djangoがなきゃありえなかったね！
昔のPythonコミュニティは最高だったな。ネット上の見知らぬ人たちがみんな親切だった。Rubyも同じ感じだったよ。
俺もDjangoでプログラミング始めたんだ！地元新聞社で働きながら使ってたよ。営業が広告を予約できて、Fabric.jsでレイアウトして、InDesignに送るシステムを作ったんだ。Djangoが全然邪魔にならなくて最高だった。転職したけど、Djangoは俺の心に永遠に残るよ。
俺も同じ！Djangoは初めてまともなフリーランスやソフトウェア開発をさせてくれただけじゃなく、高品質なPythonのコードや開発プラクティスも教えてくれたんだ。
Djangoって不安定とかセキュリティの問題があったって評判なの？
ていうか、MLのPhD学生がユーザーごとに物理的にDBを分けるって、どういう発想だよ？
Djangoに評判があったわけじゃなくて、新しいプロジェクトだったから安定性やセキュリティの証明がなかったんだ。俺が使い始めた頃はリリース数ヶ月で、すぐ破壊的な変更やセキュリティ問題もあったよ。
MLのPhD学生のDBの話は、優秀なコーダーと優秀な研究者は別ってこと。彼らはユーザーごとにデータ保存を嫌がると思って、別々のDBとパスワードにしたらしい。ひどい設計なのに気づかなかったんだね。俺がMySQLからPostgresに変えて、余計なミドルウェアを無くしたらパフォーマンスが100倍以上アップしたよ。
研究プロジェクトのコーダーってどうやったらなれるの？
学生なら、指導教員とかに聞けば、安く使えるからコーディングの「雑用」の仕事が見つかるよ。プロならMasters/PhDプログラムに応募するか、若くて珍しい技術のエキスパートになるかだね。給料は安いけど、契約で雇う研究室もある。助成金でPh.D.以外の研究者を雇う研究室もあるけど、専門技術と研究貢献が必須。俺はYaleでML論文の第二著者になって、研究者としての給料を得ながらコード修正やソフト開発してた。これ2010年までの話だから、今とは違うかもだけどね！
Djangoには悪評も大きなインシデントも聞いたことないな。pokemon.comみたいな巨大サイトも動かしてるし。博士号を持った人たちと仕事すると、彼らがとんでもない計画を思いつくことに驚くぜ。バカは単純にバカだけど、賢い人は天才的な方法でバカなんだよ。
＞悪評や重大なインシデントは知らないって言うけど、2006年の「magic removal」ブランチはAPI不安定の一例だったし、2007年には「new admin」もあったな。でも、大事なのは、Django 1.0以前はAPI安定性を保証してなかったってこと。1.0以降のDjangoは安定性とセキュリティでめっちゃ信頼できる評価を得てるぜ。
俺も同じだぜ。最初のWebアプリはDjangoで作ったし、長年いろんなフレームワークを試してきたけど、またDjangoでWebアプリを作るところに戻ってきたよ。
＞DjangoのORMと物理的に分離したユーザーごとのMySQLデータベースサーバーを使って複雑なフロントエンドを構築しようとしてるって？sqliteのことを聞いてないのか？このセットアップに最高なのに。
Djangoがネットワーク経由でsqliteと通信できるとは思えず、問題も解決しない。物理的分離とは、クラウド以前にユーザーアカウントでリモートDBに接続し、IoTセンサーデータを記録してたって意味だ。結局、大規模Postgresサーバーで一元集約するアーキテクチャに変え、セキュリティも実装したよ。膨大なセンサーデータを処理するためtimescaledbみたいなpgバックエンドを書いたけど、それは別の話さ。
Djangoは何年も前からデータベースルーティングをサポートしてるぜ。俺は君の（投稿の詳細から漠然と理解した）ような設定で、データレイクを使わないようにそれを乱用してきたよ。
それは俺たちが必要としてた時期（2008年か2009年頃）から1年以上経ってから追加されたんだ。俺たちのユースケースがDjangoのデータベースルーティング設計のインプットになったのはほぼ間違いないね。俺たちはかなりうるさく要求してたからな。
Web開発で20年は永遠とも言える期間だ。Djangoが長く使われてるのは、その素晴らしい設計思想の証拠だな。物事を成し遂げるフレームワーク、誕生日おめでとう。Djangoは実用的でセキュア、そして信じられないくらい安定してる。最新のトレンドを追いかけるんじゃなく、ちゃんとしたビジネスを構築したい時に選ぶべきフレームワークだ。Web上の巨大サイトのいくつかで使われてるし、今でも多くのプロジェクトにとって最高の選択肢だよ。あと20年も頑張ってくれ。
DjangoってRailsにインスパイアされてなかったっけ？
いや、違うよ。Djangoの開発はRailsがリリースされる前の2003年に始まったんだ。Railsの登場と、Pythonコミュニティでの「僕らのWeb開発はどうなるんだ？」って疑問が、フレームワークを抽出してリリースするきっかけになったのは確かだよ。長年、Railsから（良いアイデアはどこからでも）ヒントを得てきた。一番大きかったのは、Web開発は簡単であるべきっていう基本理念だね。今「Developer Experience」って呼んでるものへの注目が、Railsが世界に与えた最高の贈り物だと思うよ。
違うよ、最初はお互いに強く影響し合っていたけど、Djangoのデザイン哲学は独自のものだったと思うね。時間が経つにつれて、プログラミング言語やWebフレームワークのことだけでなく、頭の中が曖昧になってきちゃったけどさ。情報源は僕自身だよ。20年前にZopeをプログラミングしていたんだ（ほとんど嫌いだったけど、概念的には面白いこともたくさんあったな）。2006年の初めに転職して、新しい上司のおかげで2006年の2月からDjangoを使い始めたんだよ（古いインスタンスのどこかに0.96版がまだインストールされてて、まだ動くと思うな）。
Zopeか、ゾッとするね。いくつか素晴らしいアイデアはあったし、かなり大きなアプリを構築したけど、もう二度とアプリケーションサーバーの中で仕事をするくらいなら舌を噛み切った方がマシだよ。Djangoや、TurboGears、Pylonsみたいな同時代のフレームワークは、本当に新鮮な風だったな。
TurboGearsは好きだったけど、「ベストインブリード」のライブラリを使う彼らのアプローチが、その意味が変わり続けて彼らを置き去りにし、結局足を引っ張った感じだね。
そうだったね。素晴らしいアイデアだったと思うけど、他のものがそれを追い越していったんだ。Pyramidをしばらく使っていて、今でも感謝しているけど、FlaskやFastAPIなんかが存在する世界で、自分の新しいプロジェクトにPyramidを使うなんて想像できないな。
10年前、カンザス州ローレンスでDjangoの10周年を祝う対面イベントがあったんだ。その時のトーク動画はここにあるよ: https://pyvideo.org/events/django-birthday.html
昨日、20周年を祝って、10周年の時の自分のトークの注釈付き書き起こしを書いたんだ。それはDjangoの誕生秘話なんだよ: https://simonwillison.net/2025/Jul/13/django-birthday/
僕はその地域出身だから、あのイベントに参加したよ。竹製のバッジ、まだ持ってるんだ。「Documentation as Empathy」のトークは、今でもよく思い出す一つだね。その後、みんなと遊ぶのも楽しかったな。素敵な人たちだったよ。
このトークについて教えてくれてありがとう。詳細がわかってとても嬉しいよ。
今日のPythonの容赦ない批評家である僕だけど、SimonとDjangoコミュニティ全体には感謝を伝えたいね。Djangoは「batteries included」の素晴らしいフレームワークで、多くの成功したプロジェクト、企業、そしてキャリアを立ち上げてきたんだ。僕のも含まれてるよ。他のエコシステムで管理パネルを評価する時のベンチマークとして今でもpgAdminを使っていると言ったら嘘になるね。Djangoで君たちが作ったものは本当に素晴らしいよ。Djangoがなかったら、僕らは技術的にずっと遅れていただろうね。心から感謝するよ。
Pythonの容赦ない批評家なのに、どうしてDjangoが好きなの？
正直、よく知らないものを客観的に批判なんてできないよな。Go言語には、Djangoに匹敵するフレームワークはまだないし。Djangoは実用的で、余計なメタマジックも少ないし（Railsは今でも「わかんない」）、不要なレイヤーは剥がせるし、ホントいいよ。
PhoenixはDjangoにかなり近いところまで来てると思うよ。
PhoenixとElixirは大好きなんだけど、管理機能はちょっと物足りないね。まぁ、最近の開発ならpgAdminとかで十分だし、今はこれでOKって感じだけど。
もっとコメントを表示（1）
Django Adminはちょっとした罠なんだよな。強力すぎて、これでアプリを丸ごと作れるくらいなんだけど、カスタムビューや強力なフィルタリング、ACLなんかで、80%くらいはほぼ宣言的なDSLだけで片付いちゃう。でも残りの20%は？ 完全に書き直すしかなくて、沼にハマるんだ。どうせかかる時間とお金だけど、サンクコストの罠が痛い。
Djangoの公式ドキュメントにもちゃんと書いてあるじゃん、Adminはあくまで内部アプリの簡単な管理ダッシュボード用で、これ以外とかもっと複雑な場合は自分で作ることを検討しろってさ。
そうそう。その罠、Django Adminサイト自体に留まらないんだよな。ModelFormやgeneric viewsはAdminサイトの基盤になってて、それらが公開されてて使うのを推奨されてるからね。低レベルのCRUDパーミッションも同じ。ジュニア開発者が書き直さずに残りの20%をやり始めると、マジで保守が大変なことになるよ。
ジュニア開発者だけじゃないよ。昔、クライアントがDjango Adminで99.9%できたみたいなのを持ってきたんだけど、ModelFormとちょっとしたCSSでね。途中で「無理」って言って25%だけ先に受け取るべきだったな、どんどん無茶な変更リクエストが増えてさ。まぁ、仕方ないけど。
多くのフレームワークも「管理」セクションには似たような欠点があるんだよな。20%の時間で80%のところまで行けるけど、残りの20%が超大変。この問題がないか、少なくとも最小限に抑えてるフレームワークが一つあるよ。PHPのYii framework。すごく良くて過小評価されてるフレームワークだね。
https://backpex.live/ は結構いいPhoenix Adminだよ。でもDjangoのAdminはまだ無敵だけどね。
Goは標準ライブラリ重視でフレームワークは使わないっていう哲学だけど、Djangoは素晴らしいフレームワークだよ。僕のWeb開発キャリアはDjangoから始まったし、これからも20年頑張ってほしいな！
RailsはRubyの方言みたいって思うこと、たまにあるんだよね。
車の駆動系は嫌だけど内装は好きって話と一緒！Pythonで嫌なことはPythonチームのせい、Djangoで好きなことはDjangoチームのおかげなんだ。システムは別々でも共存できるよね。
これって質問にもならないんじゃない？Javaは好きだけどフレームワークは嫌い。Djangoは好きだけどPythonは大規模コードベースでは最悪。言語とツールは全然別物だよ。
「Pythonをめちゃくちゃ批判してるのにDjangoは好きなの？」って？Djangoアプリを開発するってのは、Pythonを書くってよりDjangoを書くって感覚なんだ。
ソフトウェアって何層にもなってるから、特定の層が好きってことはよくあるよね。僕はPythonもDjangoも大好き。PHPは大っ嫌いだけど、LaravelはPHPを使いやすくする優れたフレームワークだと心から認めるよ。
僕もPHPからPythonとDjangoに乗り換えたよ。またPHPを使うことになった時、LaravelはDjangoやRailsにインスパイアされてたから、本当に救いの手だったな。
15年間、本当に満足してるDjangoユーザーだよ。これからもあと15年は使いたいな！Djangoの一番大事な特徴はその安定性。Django 1.4とPython 2.6で作ったアプリを、Django 5とPython 3.13に少ない手間でアップデートできたんだから。Djangoチームの皆、本当にありがとう！
僕のキャリアは大学でDjango 0.96を使ったことから始まったんだ。今でも新しいプロジェクトでよく使うし、シアトルDjangoユーザーグループの活動にも参加してたよ。Djangoのエンジニアリングだけでなく、コミュニティの精神が僕のキャリアを大きく飛躍させてくれたんだ！
2006年にDjango 0.95から使い始めたんだ。Railsに苦労した後、Djangoは20分でHello Worldが動いて衝撃だったよ。新機能の登場からDjangoCon参加まで、長くて生産的な道のりだった。僕のキャリアはDjangoのおかげ。本当にありがとう！HBD Django！
俺はキャリアのほとんどでDjangoを使ってきたよ。他のフレームワークを使うたびに、Djangoがいかに初期原則（batteries included）を守りつつ新技術に適応してきたかを思い知らされるね。素晴らしいコミュニティが長く続いているのもすごい。他のフレームワークにも良い点はあるけど、全体的なツールとしては大規模で複雑なプロジェクトに最適だし、マイクロプロジェクトにも悪くない選択肢だと思うよ。
過去15年間Djangoを触れてきて、本当に楽しかったよ。コミュニティに参加したのは衝撃的だったし、DSFの理事や会長を務められたのは光栄だったね。あと20年もコードとコミュニティと一緒にいられるのが楽しみだよ。
Djangoで一番好きなのはバージョン管理されたドキュメントだね。どのページに行っても、1.8までさかのぼって読めるんだ。10年前のでも動くのは、DjangoがAPIの非推奨化と移行をじっくりやってるからだね。一つのドキュメントサイトが機能し続けてて、URLも変わってない。他のフレームワークだと、色々なサイトにドキュメントが散らばっててうんざりするよ。Djangoは個人的なプロジェクトで使うことが多いけど、やっぱりホームって感じだね。JavaScriptの新しいのが消えてほしいな。
最近のDjangoの唯一の課題は、Pythonの型ヒントがフレームワーク自体にネイティブにないことだね。パッケージはあるけど、Django自体に備わっててほしいな。それ以外は、すごく柔軟で楽しく使える素晴らしいフレームワークだよ。長く続いているから、Railsみたいに豊富なエコシステムがあるのも羨ましい点だね。
そうそう、型をちゃんと付けるには、ORMとモデルをアプリの他の部分から隔離してるんだ。データ取得用のセレクター層があって、Djangoのモデルオブジェクトを直接渡す代わりにdataclassesやPydanticにマッピングしてるよ。アプリが大きくなると、他のアプリのモデルを知りすぎないようにするのは良いやり方だよね。でも、このフローでも、アノテーション使うたびに「# type: ignore」しなきゃいけないんだ。Pythonのラムダが不足してるせいか、クエリセットからデータをマッピングする時、ちゃんと定義した関数にする必要があって、django-stubsのアノテーションも結局失われちゃうんだよね。
ソフトウェアがこうして長く続くのを見るのはいいね。昔、フレームワークを始めた頃、DjangoとTurboGearsを見たんだ。友達はDjangoを選んだけど、俺はTGに行ったよ。今TGがどうなってるか知らないけど、当時はSQLObjectとかMochikitとか最高だと思ったんだ。あの時、道を間違えた気がするね。PyCon Indiaの”ウェブ”パネルで、Djangoの人が言ってたんだ。「20年後、Pythonの標準ウェブフレームワークがどうなるかは分からないけど、きっとDjangoって呼ばれてるだろうね」って。プロジェクトの寿命と適応能力について話してたよ。
間違いなく今まで使った中で最高のフレームワークだね。Djangoがあるのに、なんでわざわざBackend JavaScriptなんて学ぶ必要があるんだって感じで、全然覚えようとしなかったよ。
まさに俺も！でもJavaScriptは一応勉強してるんだよね、笑。
俺はDjango 0.96から使ってて、ウェブサイトが必要な時はいつもこれに戻ってくるんだ。他のも試したけど、やっぱりDjangoが一番しっくりくるね。また20年！
2025年の目標US $300,000.00に対して、2025年7月13日現在、資金調達は25.6%で$76,707の寄付だね :(
Djangoって、すごいビジネス価値を生み出してるのに、開発資金を確保するのに苦労してるよね。オープンソースの持続可能性はほんと大変だってわかる問題だ。
うん、それはちょっと残念だね。オープンソースツールをサポートすることがいかに大事か、改めて思い知らされるよ。特に大手の資金豊富な競合と戦ってる場合、善意だけじゃ生き残れないからね。
イノベーションや透明性、コミュニティ主導の開発が続くためには、俺たちが寄付したり、広めたり、できることで協力しなくちゃいけないんだ。
このサイトでDjangoの話題が出ると、みんな褒めちぎるからなんか不思議な感じがするよ。正直、俺は今まで使ったPythonフレームワークの中で一番最悪だと思った。裏で勝手に色々やってくれるせいで、直感的にコード書くのがすごく難しかったんだ。特にデフォルトのダッシュボード機能を使うと、実行順序が全然見えなくてね。Djangoしか使わない職場で11ヶ月耐えたけど、Djangoでキャリア築けた人はすごいと思うよ。もっと批判的な意見があってもいいのにって、マジでびっくりするわ。
俺にとって、2つのことが同時に当てはまるんだ。
* Djangoは、賢くて素晴らしい人たちが開発した、すごいソフトウェアだと思う。
* 俺はDjangoを使いたくない。
Djangoは「Djangoアプリ」を作るのには無敵だね。つまり、リレーショナルDBに接続して、ORでCRUDクエリ作って、その結果をHTMLやJSONでそのまま出力したいなら最高に楽しいよ。でも、非リレーショナルバックエンドを叩いたり、自分で出力形式を決めたり、プロジェクトの他の部分で作ったSQLAlchemyモデルを再利用しようとすると、地獄を見る羽目になる。俺がやってることのほとんどは「非Djangoパターン」なんだ。でももし違ってて、PostgreSQL上で伝統的なウェブサイトをゼロから作るなら、もちろんDjangoは選択肢の上位に来るだろうね。
もっとコメントを表示（2）
たまにちょっとごちゃごちゃしてるけど、ほとんどどんな問題にも解決策があるのは素晴らしいね。唯一、全部手動でワイヤー接続しなきゃいけないのが未だに気になるけど、それ以外は他のほとんどのやつより断然いいよ。
たぶん、Djangoチュートリアルやったことないからじゃないかな？何がどうなってるのか理解したら、本当に素晴らしいってわかるよ。だって、ボイラープレートコードが全然ないんだもん。Djangoが面倒な部分を全部やってくれるから、アプリ作りに集中できるんだ。それに、全てを自分の好みに合わせてカスタマイズできる自由もあるしね。ドキュメントもすごく良くて完璧だから、分からないことがあればいつでも調べられるし。
これ聞くと嬉しいな。Djangoがなかったら、俺は今キャリアを築けてなかったと思うから。
他のスタックじゃダメだったの？
みんなキャリアはどこかでスタートするもんだよ。Djangoはもう20年もキャリアをスタートさせてきたんだからね。
たぶんね。でも、Django（とPython）に自然とフィットする色々な要素が、俺にとってはうまく機能したんだ。
DjangoとRuby on Railsの両方を使ったことがある人に聞きたいんだけど、どっちが好きで、その理由は？10年以上前にPythonを学んだけど、Rubyも学びたかったからRailsを最初のWebフレームワークにしたんだ。それでこの質問。
RailsとDjangoをプロで使ってきたけど、正直Djangoを推すよ。Railsのメタな側面は好きだけど、Pythonのライブラリエコシステムがめちゃくちゃデカくて、Djangoだけで何でもできるんだ。Railsを使うとPythonのコードベースが別になりがちだけど、Django ORMならそのままだし。ほとんどのスタートアップにはDjangoを推奨するね。でもML/AIはやらないし、必要なライブラリが決まってて一人でやるならRailsの開発速度は超速いよ。
Djangoを好む理由はいくつかあるんだ。
PythonはRubyよりずっと好きで、明示的なインポートや“たった一つのやり方”って哲学がよりスケーラブルに感じる。
Djangoも同じ哲学で、定義が明示的でデバッグしやすいんだ。
Djangoのドキュメントは最高で、良いプラクティスも教えてくれる。Rubyのドキュメントはそこが足りないと感じるね。
Djangoは長年安定してるし、メジャーバージョン間の移行も楽。
Pythonライブラリのエコシステムはもっとデカい。
Django adminとRest Frameworkはこれまでで一番の時短ツールだよ。もちろんRailsも素晴らしいフレームワークだけどね。
Railsをプロでそんなに使ったわけじゃないけど、顧客向けCRUDならRailsを選ぶね。デプロイエコシステムや開発体験がちょっと良いと思う。でもDjangoは内部ツールやPythonライブラリを組み込む必要がある場合に最高だよ。GISやカスタムBI、データアナリティクスはDjangoの明確な勝利だね。
「Djangoは内部ツールやPythonライブラリを組み込む必要がある場合に最高で、GISやカスタムBI、データアナリティクスはDjangoの明確な勝利」って言ってたけど、もっと詳しく教えてくれる？内部ツールにはDjangoテンプレートを使うの？
地球最大のGISプロジェクトであるOpenStreetMapがRailsで動いてるのに、どうしてGISでDjangoが明確に勝つって言えるの？
最大のGISプロジェクトであるOpenStreetMapが、ほとんどのプロジェクトで関連する例になるかな？
RailsとDjangoでのGISデータ処理について疑問に思ってる人のために言うと、Pythonエコシステムの方がGISデータ処理にはずっとデカいんだ。fiona、shapely、gdalとかのライブラリがもっとあるしね。Django ORMはPostGISの全機能、geosやogrのオブジェクトヘルパーをサポートしてる。RailsにはPolygonFieldやRasterサポート、それにfilter(geom__intersects=area)みたいなジオメトリフィールドクエリの代替がないんだ。
プロジェクト次第だね。JS統合が必要ならRailsの方が優れてる気がするよ。RailsのJS（import maps）はDjango（CDNからの静的リンク）と似てるけど、プロジェクト生成からesbuildを設定できるのが本当に楽なんだ。これは個人的な意見だけど、DjangoでJavaScriptをローカル開発やデプロイでハックなしで設定するすごく良い方法にはまだ満足できてないんだよね。
この記事のコメントを読んでる人はたぶんDjangoファンだから、多少は自己選択バイアスがかかるって理解しといてね。
プロとしてたくさんのMVCフレームワークを使ってきたけど、俺の意見ではRuby on Railsが多くの点で今もゴールドスタンダードだよ。Djangoは「おもちゃ」のフレームワークみたいでさ、Pythonを大学で始めた開発者が、キャリアで他の言語をマスターする必要性を感じなかったから好むんだろうね。
12年前にRailsを、16年前にDjangoを触ったよ。Java、Kotlinがメインだけど、Python、TypeScript+React、Go、Scala、PHPも経験あり。DjangoはRailsより堅牢でシンプルで好み。Pythonはそのシンプルさがデータサイエンティストにも人気だね。Rubyはメタプログラミングに凝りすぎてRailsは複雑だった。最近はFastAPIやSinatraみたいな軽量FWが好き。SQL直接使いたいし、ORMやサーバサイドMVCは不要。LLMでボイラープレートも生成できるしね。だから最近はDjangoもRailsもあまり使わないんだ。
Djangoはそのまま使えるのがいい。JSが嫌いなら、JSフレームワークが流行り廃りする中で、ずっと頑張ってくれたDjangoに感謝だね。セクシーじゃなくても貢献してくれた皆、ありがとう。
そうそう！セクシーじゃないかもしれないけど、長続きしてて投資する価値はあるね。あと10～20年は持ちそうだ。
Django大好きで、ほとんどのプロジェクトで使ってるよ。でも、もっとモダンなFrontendシステムを導入してほしいな。Reactを使った後だと、テンプレートに戻るのはきついんだ。DjangoとReactを一緒に使うのは簡単だけど、Djangoの中にモダンなFrontendソリューションがあったら最高なのにね。
涙が出たよ。2008年に大学で初のPHP案件やってた時、上司にDjangoを見せたら、それ以来PHPプロジェクトは作ってないんだって。Djangoは僕が初めて使った時より年上になったね。また次の20年を！
誕生日おめでとう、Django！音楽ジャンルならHeavy Metalだね—うるさくて、構造的で、長持ちする。5.2リリースは最近HNでも話題になったよ: https://news.ycombinator.com/item?id=43556656
僕のITキャリアの現在の局面はDjangoのおかげだね。もう約15年間プロダクションで使ってる。1.0リリース頃から使い始めたから初期の不安定さは知らず、ずっと開発が楽しかった。安定してて信頼でき、定期的に更新されてて、新人に教えやすいのも重要。ドキュメントやAPIも年々良くなってる。PostgreSQLと一緒に、組織内で後悔したことのない数少ない技術選択だよ。
