¿Desventaja de rendimiento al usar slug como clave principal/_id en mongo?

En mi opinión, no. La diferencia de rendimiento será insignificante para la mayoría de los escenarios (excepto paginación ), pero

• Surge la antigua discusión sobre las claves primarias sustitutas. Una "babosa" no es una clave muy natural. Sí, debe ser único, pero como ya señaló, cambiar el slug no debería ser imposible. Esto por sí solo evitaría que me molestara...
• Tener un _id monótono key puede ahorrarle una serie de dolores de cabeza, sobre todo para evitar la costosa paginación a través de skip y take (use $lt /$gt en el _id en su lugar).
• Hay un límite en la longitud máxima del índice en mongodb de menos que 1024 bytes. Si bien no es bonito, se permite que las URL sean mucho más . Si alguien ingresó un slug más largo, no se encontraría porque se eliminó silenciosamente del índice.
• Es una buena idea tener una interfaz consistente, es decir, usar el mismo tipo de _id en todos, o al menos, la mayoría de sus objetos. En mi código, tengo una sola excepción en la que uso un hash especial como identificación porque el valor no puede cambiar, la colección tiene tasas de escritura extremadamente altas y es grande.
• Supongamos que desea vincular el artículo en su interfaz de administración (no en el sitio público), ¿qué vínculo usaría? Normalmente el id, pero ahora el id y el slug son equivalentes. Ahora sería difícil recuperarse de un error simple (como permitir un slug vacío), ya que el usuario ni siquiera podía ir a la interfaz de administración.
• Tendrá que lidiar con problemas con el juego de caracteres. Sugeriría ni siquiera usar el slug para buscar el artículo, pero el hash del slug .

Esencialmente, terminarías con un esquema como

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique