PostgreSQL vs MariaDB para apps CRUD transaccionales

Cuando una app CRUD deja de ser un prototipo

Una app CRUD prototipo suele parecer rápida porque los datos son pequeños, el equipo es reducido y el tráfico predecible. Puedes apañarte con consultas simples, un par de índices y ajustes manuales del esquema. Entonces la app consigue usuarios reales, flujos reales y plazos reales.

El crecimiento cambia la carga de trabajo. Listas y paneles se abren todo el día. Más gente edita los mismos registros. Los jobs en background empiezan a escribir por lotes. Ahí es cuando "funcionaba ayer" se convierte en páginas lentas, timeouts aleatorios y esperas de bloqueo en horas pico.

Probablemente has cruzado la línea si ves cosas como páginas de lista que se ralentizan después de la página 20, releases que incluyen backfills de datos (no solo columnas nuevas), más "campos flex" para metadatos y cargas de integración, o tickets de soporte que dicen "guardar tarda una eternidad" en momentos de alta carga.

Es entonces cuando comparar PostgreSQL y MariaDB deja de ser una preferencia de marca y se vuelve una pregunta práctica. Para cargas transaccionales CRUD, los detalles que suelen decidir son las opciones de indexación cuando las consultas se vuelven más complejas, la seguridad de las migraciones una vez que las tablas son grandes, el almacenamiento y consulta de JSON, y las características de consulta que reducen trabajo en la aplicación.

Esto se centra en esos comportamientos de base de datos. No profundiza en dimensionado de servidores, precios de la nube o contratos de proveedor. Esos importan, pero a menudo son más fáciles de cambiar más adelante que un esquema y un estilo de consulta del que dependa tu producto.

Empieza por los requisitos de tu app, no por la marca de la base

El mejor punto de partida no es “PostgreSQL vs MariaDB”. Es el comportamiento diario de tu app: crear registros, actualizar unos pocos campos, listar resultados filtrados y mantenerse correcto cuando mucha gente actúa a la vez.

Anota qué hacen tus pantallas más concurridas. ¿Cuántas lecturas se hacen por cada escritura? ¿Cuándo ocurren los picos (logins matutinos, cierres de mes, grandes importaciones)? Captura los filtros y ordenamientos exactos en los que confías, porque esos impulsan el diseño de índices y los patrones de consulta más adelante.

Luego define tus innegociables. Para muchos equipos eso significa consistencia estricta para dinero o inventario, un rastro de auditoría de “quién cambió qué” y consultas de reporte que no se rompan cada vez que el esquema evoluciona.

La realidad operacional importa tanto como las funcionalidades. Decide si vas a usar una base de datos gestionada o autoalojada, con qué rapidez debes restaurar desde backups y cuál es tu tolerancia a ventanas de mantenimiento.

Finalmente, define “suficientemente rápido” con unos objetivos claros. Por ejemplo: latencia p95 de la API bajo carga normal (200 a 400 ms), p95 bajo concurrencia pico (quizá 2x normal), esperas máximas aceptables en bloqueos durante actualizaciones (menos de 100 ms) y límites de tiempo en backup y restore.

Fundamentos de indexación que impulsan la velocidad CRUD

La mayoría de las apps CRUD parecen rápidas hasta que las tablas alcanzan millones de filas y cada pantalla se convierte en “una lista filtrada con ordenamiento”. En ese punto, la indexación es la diferencia entre una consulta de 50 ms y un timeout de 5 segundos.

Los índices B-tree son el caballo de batalla por defecto tanto en PostgreSQL como en MariaDB. Ayudan cuando filtras por una columna, haces joins por claves y cuando tu ORDER BY coincide con el orden del índice. La diferencia real de rendimiento suele reducirse a la selectividad (cuántas filas coinciden) y si el índice puede satisfacer filtrado y ordenación sin escanear filas extra.

A medida que las apps maduran, los índices compuestos importan más que los de una sola columna. Un patrón común es filtrado multi-inquilino más un estado más un orden por tiempo, por ejemplo (tenant_id, status, created_at). Pon el filtro más consistente primero (a menudo tenant_id), luego el siguiente filtro y finalmente la columna por la que ordenas. Esto suele superar a índices separados que el optimizador no puede combinar eficientemente.

Las diferencias aparecen con índices “más inteligentes”. PostgreSQL soporta índices parciales y de expresión, que pueden ser excelentes para pantallas focalizadas (por ejemplo, indexar solo tickets “abiertos”). Son potentes, pero pueden sorprender si las consultas no coinciden exactamente con el predicado.

Los índices no son gratis. Cada inserción y actualización debe actualizar cada índice, así que es fácil mejorar una pantalla y ralentizar silenciosamente cada escritura.

Una forma simple de mantener disciplina:

• Añade un índice solo para una ruta de consulta real (una pantalla o llamada API que puedas nombrar).
• Prefiere un buen índice compuesto sobre muchos índices solapados.
• Revisa los índices tras cambios de funcionalidad y elimina el peso muerto.
• Planea mantenimiento: PostgreSQL necesita vacuum/analyze regular para evitar bloat; MariaDB también depende de buenas estadísticas y limpieza ocasional.
• Mide antes y después, en lugar de confiar en la intuición.

Indexación para pantallas reales: listas, búsqueda y paginación

La mayoría de las apps CRUD pasan su tiempo en unas pocas pantallas: una lista con filtros, una caja de búsqueda y una página de detalle. La elección de base importa menos que si tus índices coinciden con esas pantallas, pero los dos motores ofrecen herramientas diferentes una vez que las tablas crecen.

Para páginas de lista, piensa en este orden: filtrar primero, luego ordenar y después paginar. Un patrón común es “todos los tickets para la cuenta X, estado en (open, pending), más nuevos primero”. Un índice compuesto que empiece por las columnas de filtrado y termine con la columna de ordenación suele ganar.

La paginación merece cuidado especial. La paginación por offset (página 20 con OFFSET 380) se vuelve más lenta a medida que avanzas porque la base de datos aún tiene que pasar por las filas anteriores. La paginación por keyset es más estable: pasas el último valor visto (como created_at e id) y pides “las siguientes 20 anteriores a eso”. También reduce duplicados y huecos cuando llegan filas nuevas mientras se navega.

PostgreSQL tiene una opción útil para pantallas de lista: índices “covering” usando INCLUDE, que pueden permitir escaneos solo por índice cuando el mapa de visibilidad lo permite. MariaDB también puede hacer lecturas que cubran la consulta, pero normalmente lo consigues poniendo las columnas necesarias directamente en la definición del índice. Eso puede ensanchar índices y hacerlos más caros de mantener.

Probablemente necesites mejores índices si un endpoint de lista se ralentiza al crecer la tabla aunque devuelva solo 20–50 filas, el ordenado se vuelve lento a menos que quites ORDER BY, o el I/O aumenta durante filtros simples. Las consultas más largas también tienden a aumentar las esperas de bloqueo en periodos de alta carga.

Ejemplo: una pantalla de pedidos que filtra por customer_id y status y ordena por created_at suele beneficiarse de un índice que empiece por (customer_id, status, created_at). Si luego añades “buscar por número de pedido”, eso normalmente es un índice separado, no algo que se añada al índice de la lista.

Migraciones: mantener las releases seguras a medida que crecen los datos

Las migraciones dejan de ser “cambiar una tabla” rápidamente. Una vez que hay usuarios reales e historial real, también necesitas manejar backfills de datos, endurecer restricciones y limpiar antiguas formas de datos sin romper la app.

Un valor por defecto seguro es expandir, rellenar, contraer. Añade lo que necesitas de forma que no interrumpa el código existente, copia o calcula datos en pasos pequeños y luego elimina la ruta antigua solo cuando estés seguro.

En la práctica eso suele significar añadir una nueva columna nullable o una tabla, rellenar por lotes manteniendo consistencia en las escrituras, validar más tarde con restricciones como NOT NULL, claves foráneas y reglas únicas, y solo entonces eliminar columnas, índices y caminos de código antiguos.

No todos los cambios de esquema son iguales. Añadir una columna suele ser de bajo riesgo. Crear un índice puede seguir siendo costoso en tablas grandes, así que plánificalo en horas de baja carga y mide. Cambiar el tipo de una columna suele ser lo más arriesgado porque puede reescribir datos o bloquear escrituras. Un patrón más seguro común es: crear una nueva columna con el nuevo tipo, rellenarla, y luego cambiar lecturas y escrituras.

Los rollbacks también cambian de significado a escala. Revertir esquema a veces es fácil; revertir datos a menudo no lo es. Sé explícito sobre lo que puedes deshacer, especialmente si una migración incluye borrados destructivos o transformaciones con pérdida.

JSON: campos flexibles sin dolor futuro

Los campos JSON son tentadores porque te permiten lanzar más rápido: campos extra de formulario, cargas de integración, preferencias de usuario y notas de sistemas externos pueden caber sin cambiar el esquema. El truco es decidir qué pertenece a JSON y qué merece columnas reales.

Tanto en PostgreSQL como en MariaDB, JSON suele funcionar mejor cuando rara vez se filtra y mayormente se muestra, se almacena para depuración, se conserva como un blob de "configuración" por usuario o inquilino, o se usa para atributos opcionales pequeños que no impulsan reporting.

La indexación de JSON es donde los equipos se sorprenden. Consultar una clave JSON una vez es fácil. Filtrar y ordenar por ella en tablas grandes es donde el rendimiento puede colapsar. PostgreSQL tiene buenas opciones para indexar rutas JSON, pero aún necesitas disciplina: elige unas pocas claves por las que realmente filtres e indexa esas, y deja el resto como payload sin indexar. MariaDB también puede consultar JSON, pero patrones complejos de “buscar dentro de JSON” a menudo se vuelven frágiles y más difíciles de mantener rápidos.

JSON también debilita las restricciones. Es más difícil hacer cumplir “debe ser uno de estos valores” o “siempre presente” dentro de un blob no estructurado, y las herramientas de reporting generalmente prefieren columnas tipadas.

Una regla que escala: empieza con JSON para lo desconocido, pero normaliza en columnas o tablas hijas cuando (1) filtras u ordenas por ello, (2) necesitas restricciones, o (3) lo ves aparecer en dashboards cada semana. Almacenar la respuesta completa de una API de envío como JSON suele estar bien. Campos como delivery_status y carrier normalmente merecen columnas reales una vez que soporte e informes dependen de ellos.

Características de consulta que aparecen en apps maduras

Al principio, la mayoría de las apps CRUD usan SELECT, INSERT, UPDATE y DELETE simples. Más adelante, añades feeds de actividad, vistas de auditoría, informes de administración y búsquedas que deben sentirse instantáneas. Ahí es donde la elección empieza a parecer un intercambio de funcionalidades.

CTEs y subconsultas ayudan a mantener consultas complejas legibles. Son útiles cuando construyes un resultado por pasos (filtrar pedidos, unir pagos, calcular totales). Pero la legibilidad puede ocultar coste. Cuando una consulta se vuelve lenta, puede que necesites reescribir un CTE como subconsulta o join y luego revisar el plan de ejecución.

Las funciones ventana importan la primera vez que alguien pide "rankear clientes por gasto", "mostrar totales acumulados" o "último estado por ticket". A menudo reemplazan bucles complicados en la aplicación y reducen el número de consultas.

Las escrituras idempotentes son otro requisito maduro. Cuando hay reintentos (redes móviles, jobs en background), los upserts permiten escribir sin crear duplicados:

• PostgreSQL: INSERT ... ON CONFLICT
• MariaDB: INSERT ... ON DUPLICATE KEY UPDATE

La búsqueda es la funcionalidad que se cuela sin que la veas. La búsqueda full-text integrada puede cubrir catálogos de productos, bases de conocimiento y notas de soporte. Búsquedas tipo trigram son útiles para autocompletado y tolerancia a faltas. Si la búsqueda se vuelve central (ranking complejo, muchos filtros, tráfico pesado), una herramienta de búsqueda externa puede valer la pena pese a la complejidad adicional.

Ejemplo: un portal de pedidos empieza con “listar pedidos”. Un año después necesita “mostrar el último pedido de cada cliente, rankear por gasto mensual y buscar nombres con faltas ortográficas”. Esas son capacidades de base de datos, no solo trabajo de UI.

Transacciones, bloqueos y concurrencia bajo carga

Cuando el tráfico es bajo, la mayoría de las bases se comportan bien. Bajo carga, la diferencia suele estar en cómo manejas cambios concurrentes sobre los mismos datos, no en la velocidad bruta. Tanto PostgreSQL como MariaDB pueden ejecutar una carga transaccional CRUD, pero debes diseñar para la contención.

Aislamiento en lenguaje llano

Una transacción es un grupo de pasos que deben tener éxito juntos. El aislamiento controla qué ven otras sesiones mientras esos pasos se ejecutan. Un aislamiento mayor evita lecturas sorprendentes, pero puede aumentar las esperas. Muchas apps empiezan con los valores por defecto y endurecen el aislamiento solo para los flujos que realmente lo necesitan (por ejemplo, cobrar una tarjeta y actualizar un pedido).

Qué realmente causa dolor por bloqueos

Los problemas de bloqueo en apps CRUD suelen venir de unos pocos culpables repetidos: filas calientes que todos actualizan, contadores que cambian en cada acción, colas de trabajo donde muchos trabajadores intentan reclamar el mismo “siguiente job” y transacciones largas que mantienen bloqueos mientras pasa trabajo o tiempo de usuario.

Para reducir la contención, mantén las transacciones cortas, actualiza solo las columnas necesarias y evita llamadas de red dentro de una transacción.

Una práctica útil es reintentar en conflictos. Si dos agentes de soporte guardan ediciones del mismo ticket al mismo tiempo, no falles silenciosamente. Detecta el conflicto, recarga la fila más reciente y pide al usuario que vuelva a aplicar los cambios.

Para detectar problemas pronto, vigila deadlocks, transacciones de larga duración y consultas que pasan tiempo esperando en lugar de ejecutarse. Haz de los logs de consultas lentas parte de tu rutina, especialmente tras releases que añadan nuevas pantallas o jobs en background.

Operaciones que se vuelven importantes tras el lanzamiento

Tras el lanzamiento, ya no optimizas solo por velocidad de consulta. Optimizarás por recuperación, cambios seguros y rendimiento predecible.

Un siguiente paso común es añadir una réplica. El primario maneja escrituras y una réplica puede servir páginas de lectura intensiva como dashboards o reportes. Esto cambia cómo piensas sobre la frescura: algunas lecturas pueden atrasarse segundos, así que la app debe saber qué pantallas deben leer del primario (por ejemplo, “pedido recién creado”) y cuáles toleran datos ligeramente antiguos (por ejemplo, resúmenes semanales).

Los backups son solo la mitad del trabajo. Lo que importa es si puedes restaurar rápido y correctamente. Programa restauraciones de prueba regulares en un entorno separado, y valida lo básico: la app puede conectar, las tablas clave existen y las consultas críticas devuelven resultados esperados. Los equipos a menudo descubren demasiado tarde que hicieron backup de lo equivocado o que el tiempo de restauración supera su presupuesto de downtime.

Las actualizaciones también dejan de ser “clic y esperar”. Planifica una ventana de mantenimiento, lee notas de compatibilidad y prueba la ruta de actualización con una copia de producción. Incluso cambios de versión menor pueden cambiar planes de consulta o el comportamiento de índices y funciones JSON.

La observabilidad simple rinde pronto. Comienza con logs de consultas lentas y las consultas principales por tiempo total, saturación de conexiones, lag de replicación (si usas réplicas), ratio de aciertos de caché y presión de I/O, y esperas de bloqueo y eventos de deadlock.

Cómo elegir: un proceso de evaluación práctico

Si estás atascado, deja de leer listas de características y ejecuta una pequeña prueba con tu propia carga. El objetivo no es un benchmark perfecto. Es evitar sorpresas cuando las tablas lleguen a millones de filas y tu ciclo de releases se acelere.

1) Construye una prueba que se parezca a producción

Elige una porción de tu app que represente el dolor real: una o dos tablas clave, unas pocas pantallas y las rutas de escritura detrás de ellas. Recopila tus consultas principales (las que están detrás de listas, páginas de detalle y jobs en background). Carga recuentos de filas realistas (al menos 100x tus datos de prototipo, con forma similar). Añade los índices que creas necesarios, luego ejecuta las mismas consultas con los mismos filtros y ordenamientos y captura tiempos. Repite mientras ocurren escrituras (un script simple que inserte y actualice filas es suficiente).

Un ejemplo rápido es una lista de “Clientes” que filtra por estado, busca por nombre, ordena por última actividad y pagina. Esa única pantalla suele revelar si tu indexación y comportamiento del planner envejecerán bien.

2) Ensaya migraciones como una release real

Crea una copia de staging del dataset y practica cambios que sabes que vendrán: añadir una columna, cambiar un tipo, rellenar datos, añadir un índice. Mide cuánto tarda, si bloquea escrituras y qué significa realmente un rollback cuando los datos ya han cambiado.

3) Usa una tarjeta de puntuación simple

Tras las pruebas, puntúa cada opción en rendimiento para tus consultas reales, corrección y seguridad (restricciones, transacciones, casos límite), riesgo de migración (bloqueos, downtime, opciones de recuperación), esfuerzo operacional (backup/restore, replicación, monitorización) y confort del equipo.

Elige la base que reduzca el riesgo para tus próximos 12 meses, no la que gane una micro-prueba.

Errores comunes y trampas

Los problemas de base de datos más caros suelen empezar como “ganancias rápidas”. Ambas bases pueden ejecutar una app CRUD transaccional, pero los malos hábitos dañarán cualquiera de las dos cuando crezcan tráfico y datos.

Una trampa común es tratar JSON como atajo para todo. Un campo flexible “extras” está bien para datos verdaderamente opcionales, pero campos núcleo como estado, timestamps y claves foráneas deberían seguir siendo columnas reales. Si no, acabarás con filtros lentos, validación incómoda y refactors dolorosos cuando el reporting sea prioridad.

La indexación tiene su propia trampa: añadir un índice por cada filtro que ves en una pantalla. Los índices aceleran lecturas, pero ralentizan escrituras y hacen las migraciones más pesadas. Indexa lo que los usuarios usan realmente y valida con carga medida.

Las migraciones pueden morder cuando bloquean tablas. Cambios tipo big-bang como reescribir una columna grande, añadir un NOT NULL con un valor por defecto o crear un índice masivo pueden bloquear escrituras durante minutos. Divide cambios riesgosos en pasos y plánificalos en momentos de baja actividad.

Además, no confíes indefinidamente en los valores por defecto del ORM. Cuando una vista de lista pasa de 1,000 filas a 10 millones, necesitas leer planes de consulta, detectar índices faltantes y arreglar joins lentos.

Señales de advertencia rápidas: campos JSON usados para filtrado y ordenación principal, un número de índices que crece sin medir el rendimiento de escritura, migraciones que reescriben tablas grandes en un solo deploy, y paginación sin orden estable (que lleva a filas faltantes y duplicadas).

Lista rápida antes de decidir

Antes de elegir bando, haz una comprobación de realidad basada en tus pantallas más concurridas y tu proceso de release.

• ¿Pueden tus pantallas principales mantenerse rápidas en carga pico? Prueba la página de lista más lenta con filtros reales, ordenación y paginación, y confirma que tus índices coinciden con esas consultas exactas.
• ¿Puedes lanzar cambios de esquema de forma segura? Escribe un plan expandir-rellenar-contraer para el próximo cambio rompiente.
• ¿Tienes una regla clara para JSON vs columnas? Decide qué claves JSON deben ser buscables u ordenables y cuáles son verdaderamente flexibles.
• ¿Dependes de características de consulta específicas? Verifica comportamiento de upsert, funciones ventana, comportamiento de CTE y si necesitas índices funcionales o parciales.
• ¿Puedes operarlo tras el lanzamiento? Demuestra que puedes restaurar desde backup, medir consultas lentas y establecer líneas base de latencia y esperas de bloqueo.

Ejemplo: de seguimiento de pedidos simple a un portal de clientes con tráfico

Imagina un portal de clientes que empieza simple: clientes inician sesión, ven pedidos, descargan facturas y crean tickets de soporte. En la semana uno, casi cualquier base transaccional se siente bien. Las páginas cargan rápido y el esquema es pequeño.

Unos meses después aparecen los momentos de crecimiento. Los clientes piden filtros como “pedidos enviados en los últimos 30 días, pagados con tarjeta, con reembolso parcial”. Soporte quiere exportaciones rápidas a CSV para revisiones semanales. Finanzas quiere un rastro de auditoría: quién cambió el estado de una factura, cuándo y de qué a qué. Los patrones de consulta se vuelven más amplios y variados que las pantallas originales.

Ahí la decisión se vuelve sobre características específicas y cómo se comportan bajo carga real.

Si añades campos flex (instrucciones de entrega, atributos personalizados, metadata de tickets), el soporte JSON importa porque terminarás queriendo consultar dentro de esos campos. Sé honesto sobre si tu equipo indexará rutas JSON, validará formas y mantendrá el rendimiento predecible a medida que el JSON crezca.

El reporting es otro punto de presión. En el momento en que unes pedidos, facturas, pagos y tickets con muchos filtros, te importarán índices compuestos, planificación de consultas y lo fácil que sea evolucionar índices sin downtime. Las migraciones también dejan de ser “correr un script el viernes” y pasan a formar parte de cada release, porque un pequeño cambio de esquema puede tocar millones de filas.

Un camino práctico es escribir cinco pantallas reales y exportaciones que esperas en seis meses, incluir tablas de historial de auditoría desde temprano, benchmarkear con tamaño de datos realista usando tus consultas más lentas (no un CRUD de ejemplo), y documentar reglas de equipo para uso de JSON, indexación y migraciones.

Si quieres avanzar rápido sin construir cada capa a mano, AppMaster (appmaster.io) puede generar backends listos para producción, apps web y apps móviles nativas desde un modelo visual. También te empuja a tratar pantallas, filtros y procesos de negocio como cargas de consulta reales desde temprano, lo que ayuda a detectar riesgos de indexación y migración antes de que lleguen a producción.