CedarDB: una base de datos para transacciones y analítica

Una base de datos que hace dos trabajos a la vez

CedarDB, el motor de base de datos con sede en Múnich, anunció la disponibilidad limitada de CedarDB Cloud sobre el escenario de TechCrunch Disrupt, donde compite con otras 20 startups por ganar el Startup Battlefield. Su propuesta es poco habitual: un solo motor que resuelve consultas operativas (órdenes, pagos, registros del día a día) y analíticas (tendencias, preguntas en lenguaje natural sobre esos mismos datos).

Para un founder, la relevancia es directa. Si tu producto depende de agentes de IA que necesitan leer y razonar sobre datos en tiempo casi real, mantener dos sistemas separados y sincronizarlos con pipelines se vuelve un costo que crece más rápido que tu equipo.

¿Qué es CedarDB y por qué apuesta por una sola base de datos?

Tradicionalmente, las bases de datos se construyeron para una de dos tareas. Las analíticas ayudan a detectar tendencias y responder preguntas; las operativas guardan el registro diario de transacciones. CedarDB sostiene ambos mundos en el mismo motor, y según su cofundador y CEO Moritz Sichert, ese enfoque ganó relevancia con el auge de la IA agéntica.

El argumento que da a TechCrunch es concreto: muchas empresas tienen stacks de datos bien preparados para almacenar años de transacciones, pero mal preparados para responder rápido preguntas analíticas formuladas en lenguaje natural sobre esa misma información. Ese hueco es el que CedarDB ataca.

La compañía lleva una década en desarrollo. Es un spinout de la Universidad Técnica de Múnich basado en Umbra, un proyecto de investigación construido desde cero para superar en velocidad de procesamiento a los motores heredados aprovechando mejor el hardware moderno. Cinco investigadores de Umbra figuran como cofundadores: Moritz Sichert, Lukas Vogel, Philipp Fent, Dominik Durner y Christian Winter.

La promesa técnica es rendimiento más rápido sin exigir más CPUs, más memoria ni cambios profundos en la infraestructura del cliente. Es exactamente el tipo de promesa que conviene leer con escepticismo: los benchmarks propios rara vez cuentan toda la historia. Pero hay un detalle de diseño que sí es verificable y que explica buena parte de su tracción.

La compatibilidad con PostgreSQL como ventaja competitiva

CedarDB se aseguró de ser compatible con PostgreSQL, el sistema de base de datos de código abierto más extendido del mercado. Según Sichert, esa decisión mantiene bajos los costos de migración porque los usuarios no necesitan reconstruir sus aplicaciones.

Hay un segundo efecto, menos obvio: PostgreSQL sigue la lógica con la que los modelos de lenguaje están más familiarizados por su entrenamiento. En otras palabras, la compatibilidad no solo reduce fricción para los equipos de ingeniería, también facilita que un agente de IA genere consultas correctas sin traducción intermedia.

Sichert reconoce que esa elección resultó afortunada en retrospectiva, aunque no fue solo suerte. En un post, el cofundador Christian Winter detalló las prioridades que el equipo fijó al salir de la academia: confiabilidad, tolerancia a fallos y compatibilidad con herramientas populares.

No todas las decisiones fueron evidentes. El equipo debatió con fuerza si lanzar una oferta en la nube de inmediato. Al final lanzó CedarDB Enterprise como opción on-premise junto a su versión gratuita, CedarDB Community Edition, ambas anunciadas en mayo del año pasado, al mismo tiempo que una ronda semilla de 5,3 millones de euros (aproximadamente 6 millones de dólares).

La nube quedó postergada, no descartada. Tras una fase beta con usuarios de su lista de espera, la compañía anunció la disponibilidad limitada de CedarDB Cloud. Una versión totalmente gestionada y alojada en la nube debería ayudarle a ampliar su base de usuarios más allá de las grandes empresas, y a competir mejor con rivales de mayor tamaño.

Databricks y la carrera por unificar transacciones y analítica

CedarDB no es la única que llegó a esta conclusión. En su Data + AI Summit de junio, Databricks citó "la era agéntica" como razón para lanzar LTAP, una arquitectura que busca unificar transacciones, analítica, streaming y datos operativos sobre una sola copia de almacenamiento en el lakehouse, según el comunicado recogido por HPCwire.

El detalle interesante para un founder está en el diagnóstico que hace Databricks. Shanku Niyogi, vicepresidente de producto, describió en diginomica los pipelines CDC (captura de cambios) como "corrupción continua de datos": lentos, propensos a errores y caros, porque cada cambio de esquema los rompe. Databricks afirma que este año la cantidad de código escrito en el mundo creció 50 veces, y que en los próximos 12 meses se escribirá más código que en toda la historia de la programación. Gran parte de ese código lo generan agentes que necesitan leer, razonar y actuar sobre datos en tiempo casi real.

La escala del problema no es teórica. Niyogi menciona el caso de un banco grande que mantiene cientos de miles de bases de datos PostgreSQL y debe construir pipelines CDC para todas. El patrón se repite: el problema siempre existió, pero el volumen y la exigencia de inmediatez lo volvieron insostenible.

Databricks no es un competidor menor. Su comunicado afirma que más de 20.000 organizaciones en el mundo usan su plataforma, incluido el 70% de las empresas del Fortune 500, y que su producto Lakebase —construido sobre la tecnología de Neon, adquirida en 2025— ya maneja 12 millones de lanzamientos de bases de datos por día. Entre sus clientes nombrados están Block, Superhuman, Zillow y Ensemble.

Sichert interpreta el movimiento de Databricks como una señal de que existe demanda real por lo que hace CedarDB. Es una lectura razonable, aunque conviene matizarla: que un gigante valide la categoría no garantiza que una startup de 14 personas pueda capturar esa demanda.

¿Qué significa esto para tu startup?

La discusión entre bases de datos operativas y analíticas suena a problema de gran empresa, pero impacta antes de lo que parece. En cuanto tu producto incorpora un agente que consulta datos de negocio, heredas el mismo cuello de botella.

• Audita cuántos sistemas tocan tus datos hoy. Si tienes una base transaccional, un warehouse y al menos un pipeline que mueve información entre ambos, ya estás pagando el costo que CedarDB y Databricks quieren eliminar. Antes de evaluar herramientas, mide cuántas horas de ingeniería al mes se van en mantener esa sincronización.
• Evalúa la compatibilidad antes que el rendimiento. La decisión de CedarDB de adoptar PostgreSQL es la lección más transferible: elegir tecnología que no obligue a reescribir tu aplicación reduce el costo real de cambiar de proveedor. Cuando compares motores, pregunta explícitamente qué parte de tu código actual seguiría funcionando sin modificaciones.
• Diseña tus agentes para datos frescos, no para copias. Si tu agente responde con información que se sincronizó hace horas, el problema no es el modelo, es la arquitectura. Define desde el inicio cuánta latencia tolera cada caso de uso y si necesitas datos en tiempo real o basta con minutos.
• Desconfía de las cifras de rendimiento sin comparador. Databricks reporta latencias por debajo de 100 milisegundos a 12.000 consultas por segundo y mejoras de hasta 16 veces frente a stacks especializados, según diginomica, pero los sistemas contra los que se compara no están nombrados. Pide siempre pruebas con tu propia carga de trabajo.

Conclusión

CedarDB apuesta a que la separación entre datos operativos y analíticos deja de tener sentido cuando los agentes de IA se convierten en consumidores de datos. Su ventaja no es solo técnica: es haber construido sobre PostgreSQL, lo que baja la barrera para que un equipo pruebe sin comprometerse a una migración completa.

El riesgo también es claro. Compite contra compañías con recursos muy superiores y una base instalada enorme, y su equipo de 14 personas apenas empieza a servir a sus primeros usuarios en la nube. Sichert ya anticipó que necesitará ampliar el equipo cuando gane tracción, y que ahí vendrá su próxima ronda.

Para un founder hispanohablante, la lectura práctica es esta: la arquitectura de datos dejó de ser un tema de infraestructura para convertirse en un factor de velocidad de producto. Cuanto antes resuelvas cómo tus agentes acceden a datos frescos, menos deuda técnica acumularás cuando el volumen crezca.

Fuentes

• TechCrunch: CedarDB wants one database to handle both transactions and analytics
• HPCwire: Databricks Launches LTAP
• diginomica: Why Databricks calls CDC 'continuous data corruption'