Minha experiência em conjuntos de dados com esse tamanho é limitada ao MSSQL, mas pode manipular definitivamente dados desse tamanho.
Minha primeira preocupação é o tamanho dos dados. 300 milhões de registros em 150Gb são cerca de 500Kb por linha - e isso é uma grande linha. Uma fila muito grande. Se você puder normalizar para a 3ª forma normal, isso pode ajudar muito (supondo que haja dados que possam ser normalizados). Se você não vai normalizar (e apenas tem uma única tabela massiva), então um mecanismo que suporta ISAM será mais rápido do que um RDBMS, então o MySQL no modo ISAM é a escolha óbvia sobre MSSQL (desculpe, eu não tem alguma experiência com o Postgre ou Mongo)
Dito isto, o MSSQL pode lidar com uma tabela desse tamanho sem preocupações. Ele pode particionar os dados para que partes diferentes vivam em discos diferentes, para que você possa manter 1% de dados atualizados em um disco rápido e manter o restante em um disco mais lento se o orçamento for uma preocupação. Se o seu SGBD de escolha suporta isso, então pode ser um caminho sensato.
Apenas para referência, uma vez eu gerenciei um banco de dados que tinha cerca de 200 milhões de linhas em uma única tabela (mas a tabela tinha apenas 20Gb de tamanho) e com alguns tempos de consulta de indexação inteligentes ainda estavam sendo medidos em milissegundos. Isso foi normalizado para a 3ª forma normal, então havia muito LOJ para recuperar dados associados também.