Estoy planeando una base de datos para almacenar un montón de texto. (publicaciones de blog, artículos de noticias, etc.) La base de datos debe tener los campos de título, contenido (máximo 50k caracteres), fecha, enlace e idioma. El mismo contenido no puede ocurrir en un enlace. El contenido antiguo (más antiguo que 30 días, por ejemplo) se eliminará.

Ahora, el problema es la clave principal. Podría establecer un campo de incremento automático (tipo SERIAL) y usarlo como clave principal. Pero, parece estúpido y una pérdida de espacio en el disco, porque el campo no serviría para nada más que para ser una clave principal. (¿Y el campo eventualmente se agotará o no?) Y siempre está el otro problema de rendimiento: el contenido de cada nueva fila insertada debe verificarse en busca de duplicados. Entonces, la otra solución para la clave principal que he encontrado sería calcular un hash de valor de enlace + contenido sha256 y luego colocarlo en una nueva columna "hash" y usarlo como clave principal. Dos pájaros con una piedra. Por supuesto, el problema con eso son las colisiones hash. ¿Es una gran amenaza?

No tengo ninguna experiencia con PostgreSQL, y muy poca experiencia con DBMS en general, por lo que agradecería una segunda opinión antes de crear una base de datos con las características de rendimiento de un caracol en la carretera (comparación horrible).

Por favor, ayúdeme aquí si tiene alguna experiencia con grandes bases de datos. ¿Es una buena idea establecer una cadena de 64 caracteres como campo de clave principal en mi situación? (porque estoy bajo la impresión de que generalmente esto se evita)