Eu estou planejando um banco de dados para armazenar lotes de texto. (posts de blogs, artigos de notícias, etc.) O banco de dados precisa ter os campos title, content (50k characters max), data, link e idioma. O mesmo conteúdo não pode ocorrer em um link. Conteúdo antigo (mais de 30 dias, por exemplo) será excluído.

Agora, o problema é a chave primária. Eu poderia apenas definir um campo de incremento automático (tipo SERIAL) e usá-lo como uma chave primária. Mas, parece estúpido e um desperdício de espaço em disco, porque o campo não serviria a nenhum propósito a não ser uma chave primária. (e o campo pode eventualmente acabar ou não?) E sempre há outro problema de desempenho: o conteúdo de cada nova linha inserida precisa ser verificado quanto a duplicatas. Assim, a outra solução para a chave primária que eu criei seria calcular um hash sha256 de conteúdo + valor de link e, em seguida, colocar isso em uma nova coluna 'hash' e usá-la como uma chave primária. Dois pássaros com uma pedra. Claro, o problema com isso são as colisões de hash. É uma grande ameaça?

Eu não tenho nenhuma experiência com o PostgreSQL, e muito pouca experiência com o DBMS em geral, então eu gostaria de uma segunda opinião antes de criar um banco de dados com as características de desempenho de um caracol na estrada (comparação horrível).

Por favor me ajude aqui se você tiver alguma experiência com grandes bancos de dados. Definir uma cadeia de 64 caracteres como um campo de chave primária é uma boa ideia na minha situação? (porque tenho a impressão de que geralmente isso é evitado)