Este número no es tan alto como crees. En el trabajo actual, almacenamos datos de métricas para sitios web y la cantidad total de filas que tenemos es mucho mayor. Y en un trabajo anterior, trabajé con la base de datos pg que recopilaba métricas de la red móvil y recopilaba ~2 mil millones de registros por día. Así que no tengas miedo de miles de millones en número de registros.
Definitivamente necesitará particionar los datos, muy probablemente por día. Con esta cantidad de datos puedes encontrar índices bastante inútiles. Depende de los aviones que verás en EXPLAIN salida de comando. Por ejemplo, esa aplicación de telecomunicaciones no usó ningún índice porque solo ralentizarían todo el motor.
Otra pregunta es qué tan rápido necesitarás las respuestas a las consultas. Y qué pasos en granularidad (sumas sobre horas/días/semanas, etc.) para consultas que permitirá a los usuarios. Es posible que incluso necesite hacer algunas agregaciones para granularidades como semana, mes o trimestre.
Adición:
Esos ~2 mil millones de registros por día en esa aplicación de telecomunicaciones ocuparon ~290 GB por día. Y significó inserciones de ~23000 registros por segundo usando inserciones masivas con el comando COPY. Cada volumen consistía en varios miles de registros. Los datos sin procesar se dividieron por minutos. Para evitar las esperas de disco, la base de datos tenía 4 espacios de tabla en 4 discos/matrices diferentes y las particiones se distribuyeron sobre ellos. PostreSQL pudo manejarlo todo sin ningún problema. Por lo tanto, también debe pensar en la configuración HW adecuada.
Una buena idea también es mover el directorio pg_xlog a un disco o arreglo separado. No solo un sistema de archivos diferente. Todo debe ser HW separado. Los SSD que puedo recomendar solo en arreglos con la verificación de errores adecuada. Últimamente tuvimos problemas con la base de datos corrupta en un solo SSD.
