ObsessionDB

Co-fundé ObsessionDB después de años operando servicios ClickHouse® infra a escala. Seguíamos desarrollando herramientas internas para sortear el dolor operacional de gestionar tablas replicadas. Llegamos a tener 2.000 líneas de workarounds y nos dimos cuenta de que estábamos resolviendo el problema equivocado. La arquitectura era el problema. Así que la arreglamos, y ahora está abierta al público.

El producto

ObsessionDB es ClickHouse gestionado con almacenamiento y computación desacoplados. Engines compartidos en lugar de replicados. Todos los nodos comparten object storage como fuente de verdad. La computación es stateless. Sin ZooKeeper. Sin colas de replicación que se atascan a las 3 de la mañana.

Si has operado ClickHouse a escala, sabes de qué dolor hablo. Cambios de esquema que requieren ALTER en cada shard. Sincronización manual entre réplicas cuando un nodo falla a mitad de migración. Sesiones de ZK expirando bajo carga. Lidiamos con esto durante años antes de darnos cuenta de que los problemas estaban integrados en el propio ReplicatedMergeTree. Ahora simplemente no los tenemos.

Cómo funciona

Almacenamiento y computación escalan de forma independiente. No necesitas un equipo específico para gestionarlo. Tus desarrolladores, e incluso tus agentes, tienen herramientas para manejarlo programáticamente.

Almacenamiento

S3 es la fuente de verdad. Los datos se cachean en NVMe local, y si no se encuentran en ella se accede al object storage cuando se necesitan. Pagas por lo que almacenas, no por copias replicadas entre shards.

Computación

Ejecución de queries stateless en diferentes nodos de lectura/escritura. Escalan con la carga. Añade capacidad en minutos. Cuando el tráfico baja, la computación se reduce. No pagas por máquinas innecesarias.

Herramientas para desarrolladores

Protocolo nativo de ClickHouse. Tus herramientas existentes y SQL funcionan sin cambios. Construimos un CLI para migraciones de esquema, health checks, reingestiones y otras tareas diarias. Hay una consola para monitorización y una API para automatización. También mantenemos skills de IA para cosas como diseño de esquemas y optimización de queries, el tipo de conocimiento que normalmente lleva años acumular.

Para quién es esto

Equipos procesando millones de eventos que quieren utilizar ClickHouse pero no la sobrecarga de infraestructura. Ingenieros que han pasado demasiadas noches depurando inconsistencias distribuidas. Empresas que miraron los precios de servicios ClickHouse y siguieron hosteandolo de todos modos para ahorrar.

Si ya estás utilizando ClickHouse, la migración es directa. El protocolo es nativo, tus queries funcionan sin cambios. Construimos esto porque lo necesitábamos nosotros mismos.

Lo que aprendí

La mayoría de la complejidad en sistemas distribuidos viene de la arquitectura, no a pesar de ella. ReplicatedMergeTree te fuerza a gestionar la distribución. Los engines compartidos la delegan al object storage. Un enfoque crea problemas alrededor de los cuales pasas años construyendo herramientas. Una tabla distribuida simplemente no tiene esos problemas.

Los productos de infraestructura son diferentes de las aplicaciones. La fiabilidad importa más que las funcionalidades. Una base de datos caída es peor que una a la que le falta funcionalidad. Pensamos mucho en el escenario de las 3am, porque es cuando la confianza se construye o se rompe.

Empezar una empresa con personas con las que ya has trabajado importa. 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 estaba ahí desde el día uno.