しばらくTERADATAの開発を行った後に、通常のDB（業務用のSQL ServerやOracle）に戻った時がありました。
TERADATAでは、極力まとめて処理を行うのがポイントで、1000万件くらいであれば処理は数秒で終わります。
※TERADATAにもキャパシティはあるので、そのTERADATAがどこまでまとめていけるかは把握しておく必要はあります。
CSVのロードや、テーブルからテーブルへのインサートなどストレスなく処理ができます。セカンダリインデックス（いわゆるB-Treeインデックスに近いもの）は、TERADATAでは効果が低くあまり使いません。
3，4年TERADATAの開発後、通常のRDBの開発に戻った時に処理の組み方を忘れていて大変でした。TERADATAだと500万件のマスタと5000万件のトランザクションくらいであれば普通に結合しますが、通常のRDBでは結合するとなかなか結果が返ってきません。（もしかすると永遠に返ってこないかも）
TERADATAでは、カーソルの制御はほぼ行わないのですが、通常のRDBではカーソルを回してRDBの処理内に収まるように設計することが必要です。（もちろん、処理の前に、主キー、結合キーはきちんとインデックスを作成し、統計をとっておく必要があります。）
通常のRDBで設計するときは、TERADATAで扱える件数の1/100くらいの件数が扱える件数としておきかえて設計するのがベストだと考えています。
TERADATAで1000万件くらいであれば、特に考慮はしないですが、TERADATAで10億件となると、さすがに慎重に設計するので、無理なSQLは実行しません。
これを踏まえると、通常のRDBではまとめて1万件処理するのは問題ないけど、100万件処理するときは慎重に設計しようとなります。（もしかすると、今時のサーバならもっと処理できるかもしれません。今書いてるのは、ちょうど5年ほど前の話になります。）
最後に
扱うアーキテクチャに合わせた設計というのはとても大切です。
TERADATAだったら楽勝なのになーと思う前に、用意されているものできちんと開発しないといけないんですよね。きちんと、PL/SQL や transact/SQL でカーソルを回して処理を行うのが必要です。
まぁ、頭ではわかってるんです。生活水準を上げるとなかなか下げられないということを聞きますが、TERADATAならもっと楽なのになと考えてしまうのは、それに近いのかなと思いました。
