Qué cambia respecto a MongoDB

TeselaDB implementa el protocolo de MongoDB 9.0, y la batería de compatibilidad compara sus respuestas con las de un servidor MongoDB real. Aun así, hay comportamientos que cambian, porque un clúster que reparte cada colección en rangos replicados con Raft no puede, ni quiere, copiar cada detalle de un replica set. Casi todos esos cambios son garantías más fuertes. Unos pocos te piden revisar tu código. Otros añaden lo que MongoDB no tiene, como una API REST o un servidor MCP en cada nodo.

Garantías más fuertes

En MongoDB, una escritura puede tardar en aparecer en los resultados de $search, porque el índice de búsqueda se pone al día por su cuenta. En TeselaDB, una búsqueda ve todas las escrituras confirmadas antes de que empiece. Si tu aplicación esperaba a que el índice se pusiera al día antes de buscar, esa espera sobra.

La unicidad también cambia de alcance. En una colección con shard key, MongoDB solo garantiza que _id y los índices únicos lo son dentro de cada shard, salvo que el índice lleve la shard key como prefijo. En TeselaDB, _id es único en todo el clúster, y un índice único también, sin ese prefijo. Las comprobaciones de unicidad que hacías en la aplicación para cubrir ese hueco se pueden quitar.

Las lecturas local y available devuelven siempre datos confirmados por la mayoría, así que no ves escrituras que luego se pierdan. Dentro de una transacción, local, majority y snapshot leen la misma instantánea, la de la marca de lectura de la transacción.

Las puntuaciones de búsqueda usan las estadísticas de toda la colección. En un clúster de MongoDB con shards, cada shard puntúa con las suyas. La puntuación depende entonces de cómo se repartan los datos. Aquí coinciden con las de un replica set con los mismos documentos y son las mismas en todas las réplicas, sin depender del historial de fusiones de cada una. La salida de $group también sale siempre en el mismo orden para los mismos datos, cuando en MongoDB puede cambiar de una ejecución a otra.

Lo que tienes que revisar

El primer punto es el orden. MongoDB no garantiza ningún orden en un find sin sort, aunque a menudo devuelve los documentos en el de inserción. TeselaDB los devuelve en el orden de su clave dentro de cada rango. Si tu código dependía de ver primero lo que insertaste primero, pide sort. Lo mismo vale para los empates. Las lecturas sin orden, los empates de $sort y los identificadores que lista un índice al hacerse único siguen el orden de _id o de clave, y en un empate puede cambiar qué valor igual conserva $group. Si te importa cuál queda, ordena de forma explícita antes de agrupar, porque es la única manera de que el resultado no dependa de cómo están guardados los documentos.

El segundo son las funciones obsoletas. Lo que MongoDB marca como obsoleto en la versión 9.0 no existe en TeselaDB, que responde como MongoDB responde a algo que no existe. Es el caso de $substr o de los filtros de índice, y cada uso se cambia por el sustituto que indica la documentación de MongoDB. Hay excepciones. isMaster, collStats, mapReduce y la preferencia hedge se mantienen con el comportamiento de MongoDB, porque los drivers, mongosh y las herramientas siguen enviándolos. En código nuevo conviene usar hello, $collStats y el framework de agregación.

El tercero son las claves que siempre crecen. Un ObjectId o una fecha de creación como clave concentran las escrituras en el último rango, que vive en un solo nodo. En colecciones con mucho tráfico, usa otra clave o crea el índice con teselaBuckets, que reparte sus entradas en cubos hash. El planificador junta los cubos al leer, así que las consultas por fecha no cambian.

Quedan detalles menores. Un índice comodín que intentas convertir en único con collMod falla con el error 67, donde MongoDB acepta la orden y escribe un índice no válido. Al convertir una colección en limitada, los documentos se copian en orden de _id, así que si la colección supera el tamaño sobreviven otros que en MongoDB.

Lo que se añade

Cada nodo sirve además una API REST con OpenAPI y un servidor MCP para agentes. El servidor MCP arranca en solo lectura, sus herramientas de agregación rechazan $out y $merge, e implementa Streamable HTTP y stdio. El cifrado en disco viene en el mismo binario y, sin --encryptionKeyFile, saca la clave de la PKI del clúster. También hay parámetros de clúster propios, como teselaHistoryRetention, que fija cuánto historial se conserva. Nada de esto cambia el protocolo de MongoDB, así que solo lo usas si te conviene.

Dónde mirar cada caso

La lista completa, con lo que hace MongoDB, lo que hace TeselaDB y qué hacer en cada caso, está en Diferencias con MongoDB. El estado de cada orden y de cada operador o etapa está en Compatibilidad. Antes de migrar, conviene buscar en tu código los find sin sort, las funciones obsoletas y las claves que siempre crecen, que son los tres puntos que pueden cambiar lo que ve tu aplicación.