Cuándo tu app hecha con IA realmente necesita una base de datos de verdad (y cuándo no)

¿Qué hace realmente una base de datos?

El trabajo completo de una base de datos es asegurarse de que dos personas no puedan accidentalmente sobrescribir o destruir el trabajo de la otra mientras usan la misma app — la velocidad, la estructura y las búsquedas complejas son solo efectos secundarios de resolver ese único problema.

Construiste tu app con IA. Funciona. Guarda datos en archivos o en una hoja de cálculo. Todo se siente bien.

Entonces pasa una de estas dos cosas:

Tu app se vuelve más lenta cada vez que alguien la usa.
Dos usuarios intentan usarla al mismo tiempo y algo se rompe.

Ninguno de estos fallos es obvio hasta que ya es tarde. Ambos son problemas de base de datos disfrazados.

Si todavía usas archivos o hojas de cálculo, probablemente aún no tienes una base de datos. Y está bien. Pero deberías conocer las señales de que estás a punto de necesitar una.

¿Cuándo está bien usar solo archivos en lugar de una base de datos?

Los archivos funcionan bien mientras seas la única persona que usa la app y los cambios sean poco frecuentes — esa es toda la prueba.

¿El portafolio de un freelancer? Los archivos son perfectos. ¿Un rastreador personal de gastos? Los archivos están bien. ¿Un proyecto de hobby con un solo usuario? No lo compliques.

Señales reales de que los archivos están funcionando:

Solo una persona usa la app a la vez (o los usuarios están desconectados mientras otros trabajan).
Actualizas los datos con poca frecuencia (una vez al día, una vez a la semana, una vez al mes).
Perder los últimos 30 segundos de trabajo es aceptable (tu builder puede simplemente intentarlo de nuevo).
El archivo de datos es lo bastante pequeño como para enviarlo por correo (menos de 10 MB).

Si las cuatro son ciertas, quédate con archivos. En serio. La simplicidad es una ventaja, no una limitación.

¿Por qué mi app hecha con IA se está volviendo lenta?

Tu app se vuelve lenta porque el archivo en el que guarda sigue creciendo, y tu builder está cargando el archivo completo en memoria cada vez que necesita cambiar algo — un costo que apenas se nota al principio y se vuelve doloroso a medida que crece el archivo.

Lo notas como una sensación. Tu app se siente más lenta que antes. Hacer clic en un botón toma un segundo extra. Buscar es visiblemente más lento. No cambiaste el código — ¿por qué es más lento? Aquí está el patrón:

La app carga el archivo de datos completo (100 líneas, rápido).
Un usuario agrega un registro (ahora 101 líneas).
La app vuelve a leer el archivo entero para verificar (todavía rápido).
Después de 2,000 registros, leer el archivo toma 2 segundos.
Después de 10,000 registros, toma 20 segundos.

No es exponencial, pero se vuelve notorio alrededor de los 5,000 registros y se vuelve doloroso alrededor de los 20,000.

Primera solución (antes de agregar una base de datos): Pídele a tu builder que cargue los datos bajo demanda. Que cargue solo los registros que estás mostrando, o solo las columnas que estás enseñando. Muchas apps pueden seguir con archivos siendo más inteligentes sobre qué cargan.

Cuándo pasar a una base de datos: Cuando tienes más de 50,000 registros de datos, o cuando la lentitud persiste incluso después de optimizar las cargas.

¿Por qué mi app perdió datos cuando dos personas la usaron al mismo tiempo?

Esto pasa porque dos personas pueden editar el mismo archivo a la vez y la app no tiene forma de saberlo — quien guarda segundo gana, y los cambios de la primera persona desaparecen en silencio. Se llama “escritura en conflicto”, y es un error clásico de pérdida de datos.

Ambas personas ven sus propios cambios en su pantalla. Las dos hacen clic en “guardar”. Sabrás que esto está pasando si:

Los usuarios reportan datos faltantes de vez en cuando (especialmente si hay varias personas en la app al mismo tiempo).
Los usuarios reportan ver los cambios de otras personas “deshechos” sin explicación.
Dos usuarios editan el mismo registro y las ediciones de uno desaparecen.
Recibes mensajes como “juro que agregué esto ayer y ahora ya no está”.

Esto no es culpa de la app. Es una limitación de cómo funcionan los archivos. No hay una buena forma de manejar esto sin una base de datos.

Cuándo pasar a una base de datos: En cuanto dos personas estén usando la app al mismo tiempo, incluso si todavía no ha fallado.

¿Por qué mi app no puede manejar búsquedas complejas con archivos?

Porque con archivos, tu builder tiene que cargar y filtrar cada conjunto de datos relacionado a mano, un paso a la vez, en lugar de hacer una sola pregunta y obtener una sola respuesta — una base de datos hace el mismo trabajo en milisegundos con una sola consulta.

Digamos que quieres encontrar “todas las facturas sin pagar de clientes en California que no han sido contactados en la última semana”. Con archivos, tu builder tiene que:

Cargar todas las facturas.
Filtrar por unpaid = true.
Cargar todos los clientes y hacer coincidir por ID.
Filtrar por state = “CA”.
Cargar todos los registros de contacto y hacer coincidir por ID de cliente.
Filtrar por fecha > hace una semana.

Con una base de datos, escribes una sola consulta y hace todo eso en milisegundos.

Cuándo pasar a una base de datos: Cuando tu builder dice “necesitaría escribir código personalizado para responder eso”. O cuando notas que la app hace mucho trabajo solo para mostrarte datos filtrados.

¿Qué debo decirle a mi builder cuando necesito una base de datos?

Dile claramente qué está fallando y pide un plan — algo como: “La app se está [volviendo lenta/ha tenido datos faltantes/necesita búsquedas más complejas]. Creo que deberíamos agregar una base de datos. ¿Qué tan grande es ese cambio?”

La mayoría de los builders pueden mover una app de archivos a una base de datos en 1–2 días para apps pequeñas, unos días más para las grandes. El proceso es:

Mantener la app mayormente igual (los usuarios no verán un cambio grande).
Conectar un backend de base de datos (todavía se ve como archivos para el resto del código, pero por debajo es una base de datos).
Probarlo a fondo (porque mover datos es una operación delicada).
Correr ambos en paralelo durante una semana hasta tener confianza.

El builder podría preguntar:

“¿Deberíamos usar PostgreSQL, MySQL, o algo más?”
- Tu respuesta: “Lo que te resulte más cómodo. No sé la diferencia, pero confío en ti.”
“Esto tomará 3 días. ¿Vale la pena?”
- Tu respuesta: “Si de todos modos tenemos que movernos, es mejor antes que después, cuando haya más datos.”
“¿Deberíamos migrar los datos anteriores?”
- Tu respuesta: “Sí, a menos que sean menos de 100 registros, entonces empezar de cero está bien.”

¿Necesito entender de bases de datos yo mismo?

No — no necesitas saber qué es una base de datos, aprender SQL, ni comparar PostgreSQL contra MySQL. Todo lo que necesitas decirle a tu builder es: “Dos personas pueden usar la app al mismo tiempo sin perder el trabajo de la otra.”

Eso es todo. Tu builder puede elegir la base de datos. Una simple como SQLite (para una app personal o de equipo con menos de 10 usuarios concurrentes) o PostgreSQL (para algo más grande) cumplen ese trabajo.

¿Cómo sé si mi app necesita una base de datos?

Marca cuáles de estas cuatro te aplican — dos o más casillas marcadas significa que es hora de agregar una base de datos ahora.

Lentitud: La app se sentía más rápida hace 3 meses, ahora se siente más lenta. El archivo de datos pesa más de 20 MB o tiene más de 10,000 registros.
Pérdida de datos: Los cambios de alguien desaparecieron, o varios usuarios reportaron ediciones faltantes.
Complejidad: Quieres hacer preguntas como “muéstrame X filtrado por Y” y el builder dice “eso es difícil de hacer con archivos”.
Usuarios: Más de una persona usa la app al mismo tiempo (incluso ocasionalmente).

Si marcaste dos o más casillas, tu app está lista para una base de datos.

Si marcaste cero casillas, tus archivos están bien. Quédate con ellos. La simplicidad tiene valor.

Si marcaste una casilla, pregúntale a tu builder: “¿Es esto lo bastante rápido como para vivir con ello otros 6 meses?” Si sí, espera. Si no, muévete ahora.