TeselaDB 0.1

La primera versión de TeselaDB se publica como imagen de Docker y como un solo binario para Linux x86_64, Linux aarch64 y macOS Apple Silicon. En Linux la usas en producción y en desarrollo, nativa o en Docker. En macOS sirve para desarrollar, sin garantías de latencia. Aquí tienes cómo arrancarla en un minuto, qué hace cada pieza de la versión y cuánto tiempo va a recibir parches.

Arrancar un nodo

docker run -d --name teseladb -p 27017:27017 viuzi/teseladb:latest \
  start --dbpath /data --bind_ip 0.0.0.0
until docker logs teseladb 2>&1 | grep -q '^ready'; do sleep 1; done
ROOT_PASSWORD=$(docker exec teseladb cat /data/root-credentials.txt | sed -n 's/^password=//p')
docker cp teseladb:/data/pki/ca.pem ./ca.pem
export TESELADB_URI="mongodb://root:$ROOT_PASSWORD@127.0.0.1:27017/?tls=true&tlsCAFile=./ca.pem&authSource=admin"
mongosh "$TESELADB_URI" --quiet --eval 'db.runCommand({ ping: 1 }).ok'

Te bastan Docker y mongosh. El nodo de la primera orden arranca con TLS y usuarios. En el primer arranque crea su propia CA, firma con ella su certificado y genera para root una contraseña de 32 caracteres, que deja en /data/root-credentials.txt; las órdenes siguientes sacan del contenedor esa contraseña y la CA. Cuando mongosh imprime 1, el nodo acepta conexiones. Para borrarlo todo al terminar basta con docker rm -f teseladb, porque los datos viven dentro del contenedor.

El protocolo de MongoDB 9.0

TeselaDB implementa el protocolo de MongoDB 9.0, así que conectas con los drivers oficiales y con mongosh sin cambiar de librería. Tu aplicación sigue usando find, aggregate, los índices y las transacciones que ya conoce. Las diferencias con MongoDB, que existen, están una a una en Diferencias con MongoDB, y la compatibilidad dice qué comandos y operadores funcionan.

Rangos que se dividen y se reparten

Los datos de cada colección se guardan ordenados por clave y cortados en rangos. Cada rango tiene tres réplicas en nodos distintos y su propio grupo Raft, con una réplica líder que propone las escrituras. Un rango se divide al superar 64 MiB de datos vivos o 512 MiB en disco con sus versiones, o cuando recibe demasiada carga. Dos vecinos de menos de 16 MiB, fríos durante 10 minutos y con las mismas réplicas se fusionan. No eliges una clave de fragmentación ni mueves datos a mano: el clúster reparte los rangos y sus líderes entre los nodos que tenga. Lo explica con dibujos Rangos y réplicas.

Cuando cae un nodo, las réplicas de los rangos que lideraba eligen un líder nuevo entre las que quedan. Cada rango sigue aceptando lecturas y escrituras mientras responda la mayoría de sus réplicas, que con tres réplicas son dos. Los drivers reintentan la operación en curso; si era una escritura, el rango la aplica una sola vez. La guía Matar un nodo y verlo volver lo enseña con un clúster de tres nodos en Docker.

Transacciones entre rangos

Una transacción puede tocar documentos de varios rangos y de varios nodos y se confirma de forma atómica, con aislamiento por instantánea. Si todas sus claves caen en un mismo rango, el líder la confirma con una sola escritura. Si no, cada rango guarda versiones provisionales y un registro de transacción decide si se confirma o se anula. Para tu código la semántica es la de MongoDB: withTransaction reintenta cuando debe, y un conflicto con otra escritura da WriteConflict con la etiqueta TransientTransactionError. El recorrido completo está en Transacciones distribuidas.

Búsqueda en el servidor

$text, $search y $vectorSearch funcionan en el mismo servidor que guarda los datos. No tienes que arrancar ni sincronizar un proceso de búsqueda aparte. Para buscar por significado guardas el vector como un campo más del documento, creas un índice de búsqueda de tipo vectorSearch y lo consultas desde una etapa de agregación, como explica Búsqueda vectorial.

Seguridad desde el primer arranque

El nodo arranca con TLS en todos los puertos, usuarios obligatorios y autorización en cada comando. Los nodos se comunican entre sí con TLS 1.3 y certificado en los dos extremos, firmado por la CA del clúster, de modo que una máquina sin ese certificado no puede unirse ni leer el tráfico. Los drivers se autentican con los mecanismos de MongoDB. El cifrado en reposo y la auditoría también vienen en esta versión. El reparto por capas está en Visión general de la seguridad.

API REST y servidor MCP

Cada ruta de la API REST equivale a un comando de MongoDB y se describe con OpenAPI 3.1. Cada nodo tiene también un servidor del Model Context Protocol, en el puerto 27080, con las herramientas de base de datos de MongoDB MCP Server con sus mismos nombres y argumentos. Los dos usan claves de API, que crea teseladb admin apikey create y que llevan como mucho los roles del usuario al que pertenecen. Para empezar, sigue Primeros pasos con la API REST o Servidor MCP.

Problemas conocidos

En macOS no hay garantías de latencia. Úsalo para desarrollar y despliega en Linux. Las notas no recogen cambios incompatibles ni correcciones, porque no hay una versión anterior con la que comparar.

Cuánto se mantiene

Las versiones se numeran MAYOR.MENOR.PARCHE. Un parche solo trae correcciones, una menor trae funciones nuevas y en las dos basta con cambiar el binario nodo a nodo. Una mayor puede traer cambios incompatibles, así que antes de instalarla lees sus notas. Reciben parches la versión menor más reciente y la anterior: al salir la 0.3, la 0.1 deja de recibirlos. Actualiza de una menor a la siguiente sin saltarte ninguna, porque la actualización nodo a nodo se prueba entre una menor y la siguiente. Lo detalla la política de versiones y soporte.

Las notas completas están en Notas de la versión 0.1.0, y la descarga, en la página de descargas.