--NoSQLテクノロジの方が今日のデータの需要を満たせるのではないか、という議論が今も続いているようです。そうした話し合いについては、どのようにお考えですか。過去と同じことの繰り返し、過去の過ちや教訓は何かありますか。またこの議論にPostgreSQLはどのように関わってくるのでしょうか。
その議論には複数の側面があります。1つ目は、クラスタリングとデータのシャーディングです。2つ目は、インクリメンタル開発を支援し、開発者とデータベース管理者（DBA）の冗長な話し合いを排除する極めて柔軟なデータモデルです。3つ目は、SQL言語の細かな点を取り除くWeb 2.0向けプログラミング言語との容易な統合です。
クラスタリングとシャーディングはいくつかの決定において何らかの役割を果たすかもしれませんが、多くの場合、価値を生むまでの時間（time to value）や市場への迅速な製品投入（speed to market）、開発の容易さの方がはるかに重要です。
JSONとJSONBによって、Postgresは優れたデータモデルの柔軟性を提供し、開発者が半構造（JSON）と高度な構造（ANSI SQL）の間でデータを移行させることを可能にします。アプリケーションのデザインが成熟するにしたがって、明確な構造が生まれてくることがこれまでの経験から分かっています。そして、開発者は大半のNoSQLのみのデータベースよりも多くの機能をPostgresで利用することができます。Postgresはこの分野でより大きな役割を果たすようになっており、Postgresのエキスパートになることを望んでいない開発者に対するサポートも改善され始めている、と多くの開発言語コミュニティーが認めるようになっています。
過去の教訓については、リレーショナルシステムはたいてい新しいテクノロジに順応し、2つの異なるものそれぞれの一番良い部分をユーザーに提供するということを歴史は示しています。Postgresはキーバリューストア（KVS）を2006年に実装しているので、スキーマレスなKVSを構築することが可能ですが、PostgresではACID準拠も実現できます。これは、この機能が現在ほどの認知度を得るはるか前に実現していました。PostgresのJSONに関する進歩が示しているように、ほかのNoSQLテクノロジについても、同じことが起こっています。Postgresだと、これらのNoSQL機能がACID準拠とリレーショナル機能の両方の恩恵を受けられるという利点があります。
Postgresは「Not only SQL」という形で、NoSQLとSQLの一番良い部分をアプリケーションチームに提供します。
