データベース（RDBS)でMAX1000万件レコードまでのデータを入れたり、参照したりするシステムを考えています。MAX1000万件レコード、bigint型のカラムが10カラム、1日5000件ほどのINSERTを想定しています。

一応、システム屋さんです。
止まっちゃいけないシステムを扱うことが多いので、ちょっと気にし過ぎかもしれませんが、気になることは幾つもあります。

• insert 以外 (update, delete, select) の呼量
• テーブルの設計 (特に、インデックス)
• 想定している同時接続数
• DB をアクセスするアプリの機能
• 使えるメモリ
• CPU の性能

それぞれ、互いに絡んでくるので、質問で挙げられている程度の情報だと、それぞれの項目について個別にどうこう、ということが言いにくいです。

まず気になったのは呼量です。
データを入れっぱなし、ということは無いですよね。
インターネットに接続されているサーバを使うということは、検索前提だと思います。
インデックスをどう張るかで、性能は全然変わります。
やたらに張れば良いというわけではなく、意味も無く増やすと、インデックスもディスクを使いますし、更新系の操作の負荷を増やすことにつながります。
CPU の負荷が増えるということは、CPU の性能が大事になります。

多少、インデックスの張り方が悪くても、メモリをじゃぶじゃぶ使って、DB のバッファを増やしたり、アクセスするアプリのキャッシュ機能 (PHP だったら memcached のような) を使うことで、性能の改善はできます。
但し、利用できるメモリがあれば、です。

テーブルの構造が単純で、アプリもあまり凝ってなくて、単発の性能は問題が無くても、同時に何人使用する（という想定）か、というのも重要です。
Apache や MySQL の同時接続数を増やすしかありませんが、当然、メモリは必要になります。
多重度を増やして、大量の処理をさばくということになれば、CPU に要求される性能は高いものになり案素。

VPS を想定しているのであれば、物理的なホストのリソースを複数で分け合うわけですから、CPU タイムやメモリの使用量に対する制限が出てくることも想定されます。


後、ちょっと気になってるのは、

さほど気にせずずっと動くものでしょうか。

1000万レコードで、5000件/日の insert だと、単純に割り算をすると五年半くらいということになります。
「ずっと」というには、ぼくの感覚としてはちょっと短いかな、という気もしますが、通常のシステムであればハードのリプレースを行うくらいの期間なので、レンタルサーバなら借り換えてるよ、ということでしょうか。