ObsessionDB

Cofundé ObsessionDB después de años operando infraestructura ClickHouse® a escala. No parábamos de escribir herramientas internas para capear el dolor operativo de mantener tablas replicadas. Cuando acumulamos 2.000 líneas de parches, nos cayó la ficha: estábamos atacando el problema equivocado. El problema era la arquitectura en sí. La rediseñamos, y ahora el resultado está abierto al público.

El producto

ObsessionDB es ClickHouse gestionado con almacenamiento y cómputo desacoplados. Shared engines en vez de Replicated. Todos los nodos comparten object storage como fuente de verdad. El cómputo es stateless. Sin ZooKeeper. Sin colas de replicación atascándose a las 3 de la mañana.

Si has operado ClickHouse a escala, sabes exactamente de qué hablo. Cambios de esquema que exigen ALTER en cada shard. Deriva entre réplicas cuando un nodo cae a mitad de migración. Sesiones de ZK expirando bajo carga. Convivimos con esto años hasta que entendimos que los problemas venían de serie con ReplicatedMergeTree. Ahora, directamente, no existen.

Cómo funciona

Almacenamiento y cómputo escalan por separado. No hace falta un equipo de plataforma para gestionarlo. Tus desarrolladores --e incluso tus agentes-- tienen herramientas para manejarlo de forma programática.

Almacenamiento

S3 es la fuente de verdad. Los datos calientes se cachean en NVMe local; los fríos se traen de object storage bajo demanda. Pagas por lo que almacenas, no por copias replicadas entre shards.

Computación

Ejecución stateless de queries en nodos de lectura/escritura independientes. Escalan con la carga. Añadir capacidad lleva minutos. Cuando baja el tráfico, el cómputo se reduce. No pagas por máquinas ociosas.

Herramientas para desarrolladores

Protocolo nativo de ClickHouse. Tus herramientas y SQL actuales funcionan tal cual. Desarrollamos un CLI para migraciones de esquema, health checks, reingestiones y tareas del día a día. Hay una consola de monitorización y una API de automatización. También mantenemos skills de IA para diseño de esquemas y optimización de queries: el tipo de conocimiento que suele costar años acumular.

Para quién es esto

Equipos que procesan millones de eventos y quieren ClickHouse sin la carga operativa. Ingenieros hartos de pasar noches depurando inconsistencias entre réplicas. Empresas que vieron los precios de ClickHouse gestionado y decidieron seguir con self-hosting.

Si ya usas ClickHouse, migrar es directo. El protocolo es nativo, tus queries funcionan sin tocar nada. Construimos esto porque lo necesitábamos nosotros primero.

Lo que aprendí

La mayor parte de la complejidad en sistemas distribuidos no llega a pesar de la arquitectura, sino por culpa de ella. ReplicatedMergeTree te obliga a gestionar la distribución. Los shared engines la delegan al object storage. Un enfoque genera problemas que acabas parcheando durante años. El otro, sencillamente, no los tiene.

Los productos de infraestructura no se parecen a las aplicaciones. La fiabilidad pesa más que las funcionalidades. Una base de datos caída es peor que una a la que le falte alguna feature. Pensamos mucho en el escenario de las 3 de la mañana, porque la confianza se gana --o se pierde-- justo ahí.

Montar una empresa con gente con la que ya has trabajado marca la diferencia. Ya conocíamos el estilo y los puntos fuertes de cada uno. Sin sorpresas sobre quién se encarga de qué. Los debates técnicos son productivos porque la confianza ya estaba desde el primer día.