El costo 15x de una mala decisión de base de datos: lecciones sobre el momento de decidir

Medí el costo de una decisión de base de datos en tres sistemas de producción. El costo de migración creció 15x en tres años de datos acumulados y dependencias de esquema.

TL;DR

La mayoría de los ingenieros invierten el momento de sus decisiones: deliberan durante días sobre opciones reversibles (qué biblioteca de cliente API usar) y toman decisiones irreversibles en minutos (el esquema de base de datos durante la planificación de sprint). Ray Dalio y Jeff Bezos describen el mismo marco desde ángulos diferentes: las decisiones reversibles deben tomarse rápido porque la demora cuesta más que la imperfección. Las decisiones irreversibles merecen un análisis proporcional a lo que está en juego. Aprendí esto de la manera difícil en tres sistemas donde los atajos tempranos en el esquema se acumularon hasta convertirse en costos de migración de seis cifras.

---

La migración que me enseñó

En mi primer año en ZipRecruiter, heredé un sistema donde el equipo original había elegido un esquema desnormalizado para acelerar el desarrollo inicial. La decisión tenía sentido en ese momento: enviar rápido, normalizar después. “Después” nunca llegó.

Para el segundo año, tres servicios dependían de la estructura desnormalizada. Para el tercer año, el esquema había acumulado 14 meses de datos de producción, relaciones de clave foránea que asumían el diseño desnormalizado y seis consultas de reportes que se romperían con cualquier cambio estructural.

El costo de migración en el mes uno habría sido aproximadamente dos días de ingeniería. En el mes doce, dos semanas. En el mes treinta y seis, la estimación era de tres meses de tiempo de ingeniería dedicado, más un despliegue gradual con lógica de doble escritura para evitar tiempo de inactividad. Ese es el multiplicador de 15x: no porque el problema se volvió más difícil, sino porque el radio de impacto se expandió con cada mes de dependencias acumuladas.¹

---

El marco

Decisiones reversibles: decida en minutos

Elegir un framework de frontend para un prototipo. Escoger una convención de nombres para variables. Seleccionar una región de nube para staging. Decidir qué artículo de blog escribir primero.

Todas comparten un rasgo: cambiar de rumbo cuesta aproximadamente lo mismo sin importar cuándo se cambie. La demora desperdicia tiempo sin mejorar el resultado.²

Mi prueba: Si puedo deshacer esta decisión la próxima semana con menos de un día de trabajo, decido ahora.

Cuando construí este sitio, elegí HTMX sobre React en unos diez minutos. Si HTMX hubiera sido la opción equivocada, cambiar de framework en un sitio personal con plantillas renderizadas en el servidor habría tomado un fin de semana. El bajo costo de reversión significaba que la velocidad importaba más que el análisis.

Decisiones irreversibles: decida en días

Elegir un motor de base de datos para datos de clientes. Definir un contrato de API del que dependen sistemas externos. Seleccionar una arquitectura de hooks sobre la cual se construirán 86 hooks.

Estas se acumulan. El costo de reversión crece con el tiempo, frecuentemente de manera exponencial.³

Mi prueba: Si el costo de deshacer esta decisión se duplica cada seis meses, invierto un análisis proporcional a lo que está en juego.

Mi arquitectura de hooks en .claude/ es un ejemplo de una decisión irreversible bien tomada. Pasé dos semanas diseñando el modelo de ciclo de vida de hooks (PreToolUse, PostToolUse, Stop y otros tres) antes de escribir un solo hook. Ese diseño ahora soporta 86 hooks en seguridad de git, control de recursión, aplicación de filosofía, puertas de calidad y observabilidad. Cambiar el modelo de ciclo de vida en este punto requeriría reescribir cada hook. El análisis inicial se pagó solo muchas veces.⁴

---

Cinco decisiones que acerté y en las que me equivoqué

Acierto: elegir CSS puro sobre Tailwind

Tipo: Reversible. Tiempo invertido: 20 minutos.

Elegí CSS puro con propiedades personalizadas sobre Tailwind para este sitio. Si hubiera sido incorrecto, podría haber migrado a Tailwind en un fin de semana. La decisión tomó 20 minutos: valoré aprender los fundamentos de CSS por encima de la productividad del framework. Dos años después, me alegra haber elegido CSS puro porque cada optimización (lograr puntuaciones perfectas en Lighthouse) requería entender qué hacía realmente el CSS. Pero la decisión podría haber ido en cualquier dirección sin consecuencias.

Acierto: invertir en el diseño de la arquitectura de hooks

Tipo: Irreversible. Tiempo invertido: Dos semanas.

86 hooks ahora dependen del modelo de ciclo de vida. Valió cada hora de diseño inicial.

Error: apresurar el esquema de contenido del blog

Tipo: Irreversible. Tiempo invertido: 30 minutos.

Definí la dataclass ContentMeta del artículo de blog en una sola sesión: title, slug, date, description, tags, author, published. No incluí category, series, hero_image, scripts ni styles. Cada adición posterior requirió modificar el parser, actualizar cada plantilla que consumía los metadatos y volver a probar todo el pipeline del blog. Cinco adiciones en tres meses costaron más tiempo total que lo que habría costado diseñar el esquema con cuidado desde el inicio.

Error: deliberar sobre el orden de los artículos del blog

Tipo: Reversible. Tiempo invertido: Dos horas en una sesión de planificación.

Pasé dos horas decidiendo qué artículos de blog escribir primero. El orden era completamente reversible. Debería haber empezado a escribir cualquier cosa y reordenado después según lo que aprendiera.

Acierto: diseño cuidadoso de umbrales de consenso

Tipo: Irreversible. Tiempo invertido: Una semana.

Mi sistema de deliberación usa umbrales de consenso adaptativos según la tarea: 85% para decisiones de seguridad, 80% para funciones, 65% para refactorización, 50% para documentación. Equivocarse en estos valores bloquearía trabajo legítimo (umbrales demasiado altos) o aprobaría cambios peligrosos (umbrales demasiado bajos). Probé cada umbral contra historiales de tareas reales antes de comprometerme.

---

La inversión común

Los ingenieros pasan días eligiendo bibliotecas de cliente API (reversible, bajo costo de cambio) mientras diseñan esquemas de base de datos en reuniones de planificación de sprint (irreversible, alto costo de migración).

Los gerentes hacen lo mismo: semanas evaluando herramientas de gestión de proyectos (reversible) mientras reestructuran equipos de la noche a la mañana (irreversible, alto costo humano).⁵

La inversión ocurre porque las decisiones reversibles se sienten importantes en el momento (el equipo podría juzgar mi elección de biblioteca) mientras que las decisiones irreversibles se sienten abstractas (la migración está a tres años de distancia). Los sentimientos están exactamente equivocados.

---

Dos preguntas antes de cada decisión

1. ¿Cuánto cuesta la reversión en seis meses? Si la respuesta es “trivial”, decida ahora.
2. ¿La demora mejora la información disponible? Si no surgirán nuevos datos de la espera, decida ahora.

Solo delibere cuando ambas condiciones favorezcan la espera: la reversión es costosa y surgirá mejor información con el tiempo.⁶ Todo lo demás se decide inmediatamente.

---

Conclusiones clave

Para ingenieros: - Las elecciones de stack tecnológico para prototipos son reversibles; tómelas en minutos, no en reuniones - Los esquemas de base de datos y los contratos de API son irreversibles a escala; invierta análisis inicial proporcional a cuántos sistemas dependerán de la decisión - Rastree los costos de sus decisiones; medir el multiplicador de migración de 15x cambió la forma en que evalúo la inversión inicial

Para gerentes: - Los cambios de herramientas y procesos suelen ser reversibles; haga pilotos rápidos e itere - Las decisiones de estructura de equipo y contratación tienen altos costos de reversión; delibere proporcionalmente - Cuando un equipo pasa una semana eligiendo una biblioteca, pregunte si el costo de reversión justifica el tiempo de deliberación

---

Referencias