これは長年いろんな研究が積まれながら結果としてあんまりパッとしていない分野です。
例えばOracleは自社のDB専用のサーバやチップを作れる会社ですし、更に高速なDBを求める顧客にハードウェアまで垂直統合させたアプライアンスのような製品を用意するのは順当な戦略に思います。SPARC M8というCPUはまさにOracleがDB用に拡張したプロセッサ機能を搭載しています。
https://www.oracle.com
SPARC M8 プロセッサには、特定のソフトウェア機能またはプリミティブを高速化するハードウェ ア・ユニットが組み込まれています。これらオンチップのデータ・アナリティクス・アクセラレータ（DAX）ユニットは、データベース・クエリ処理をオフロードし、リアルタイムでデータ圧縮解凍を実行し、Java ストリームを加速化します。インメモリ・クエリ・アクセラレーションは、他の プロセッサに比べて最大 7 倍の性能を実現します。インライン圧縮解凍機能により、パフォーマンスを低下させることなく、同じメモリ・フットプリントで最大 2 倍の量のデータを保存できます。 SPARC M8 プロセッサの新しいコアには、Oracle Database での実数処理を高速化する Oracle Number ユニットも組み込まれています。
非エンジニア向けの資料なので詳細は書いていませんが大まかに雰囲気は掴めます。要するにDBの内部で行われる動作の一部をハードウェア処理にオフロードする方向性のようです。DAXユニットというストリーム処理を行うコプロセッサのような物の他は特定用途のSIMD命令かアドレス自動チェック機構あたりであって、専用プロセッサだからといってあらゆる処理が桁違いに速くなるたぐいの物では無さそうです。これに需要があることは否定しませんが、DBMS専用プロセッサをゼロから作るに値する程の恩恵が万人にあるとは思いません。クラウドで安く強いx86系のCPUが使えれば大抵の用途には合致するはずです。
オフロードする、という観点でいうと今どきの大規模なデータベースはストレージとエグゼキュータが別のホストになっていることが定番で、エグゼキュータ側でトランザクション処理を実行する傍らでストレージ側でチェックポイントや永続化や簡単なフィルタ処理の一部などをオフロードされて処理する事が一般的です。DBMS専用プロセッサにその一部がオフロードできるにしても汎用プロセッサの方ができることが多いですし、充分な通信帯域さえあればオフロード先が隣のノードで構わないという戦略が経済的に勝利したと認識しています。
データベースの処理は分析処理のOLAP、トランザクション処理のOLTP、後はストリーミング等の特殊用途の3つがメインとされます。
OLAPに関してハードウェア的なリミットはほぼ無く、基本的にCPUやマシンを並べて並列度を高めれば高めるほど高速化する事が多く、その観点においてボトルネックはタスクをデータの偏りに対処しながら上手く分配するアルゴリズムや実装上の問題の方が大きいです。強いていうとソート・ジョイン・リミットなどの並列化に関してはインターコネクトで工夫をしているようです。従来はMPIが得意としていた集合通信を用いた並列処理ですが大規模なデータを巨大なクラスタの中で合理的に並列化しようと思った際にはネットワークのハードウェアのレベルから手を入れRDMAなどの力を借りて高速化する余地はまだまだあります。
例えば以下の論文はTop-KクエリをMPIを用いて高速化するというものです。
https://arxiv.org/abs/1709.05183
OLTPに関してはワークロードとしてトランザクションが衝突しまくるケースに対する根本的な解決策は見つかっておらずとにかくCPUクロックを上げるしかありません。トランザクションの衝突が問題にならないケースにおいては内部の永続化アルゴリズム自体の方がボトルネックになることが多いようです。ここについては僕のブログ記事での論文紹介もご覧ください。
https://kumagi.hatenablog.com/entry/finding-storage-glitch
永続化アルゴリズムの問題が解決した場合には恐らくディスク帯域がネックになりますが、M.2のSSDをストライピングするなどによって容易に10GB/sec以上の帯域は出せるので不揮発メモリが真に輝く時はディスクの永続化レイテンシが問題になるケースに限られ、そこへの道のりはまだまだ遠かろうという論文もあります。
https://dl.acm.org/doi/10.14778/3603581.3603586
ストリーミング処理に関しては僕はほとんどサーベイしていないので有識者の意見を待ちたいところです。