Blog

SQL vs NoSQL: Cómo Elegir

La decisión correcta de BD reduce costos, mejora performance y evita migraciones dolorosas a futuro.

Base de datos

La decisión no es "moda". Es caso de uso. SQL y NoSQL no son rivales: son herramientas para problemas diferentes. Elegir mal cuesta dinero: consultas lentas, migraciones a mitad del proyecto, y dolores de cabeza.

Definiciones Claras

SQL (Relacional): Datos organizados en tablas con filas y columnas. Relaciones entre tablas mediante claves. Ejemplos: PostgreSQL, MySQL, SQL Server, Oracle.

NoSQL (No Relacional): Datos en documentos, clave-valor, o grafos. Sin schema fijo. Escalable horizontalmente. Ejemplos: MongoDB, Redis, Firebase, Cassandra, Elasticsearch.

Comparación Técnica Completa

Aspecto SQL NoSQL
Estructura Tablas, filas, columnas. Schema definido Documentos, clave-valor. Schema flexible
Consistencia ACID: garantía de integridad (2 fases) BASE: eventual consistency (rápido)
Escalabilidad Vertical (más CPU, RAM en un servidor) Horizontal (distribuida en múltiples servidores)
Relaciones Join = consulta entre tablas (potente) Embedded o referencias (más complejo)
Queries SQL estándar (SELECT, JOIN, etc.) API específica (MongoDB queries, etc.)
Transacciones ACID completo (si falla, rollback total) Limitadas (compensating transactions)
Performance lecturas Rápido (índices, joins optimizados) Muy rápido (documentos denormalizados)
Performance escrituras grandes Limitado por locks (write bottleneck) Muy escalable (distribuye escrituras)
Costo hosting S/ 500-2,000/mes (single instance) S/ 1,000-10,000/mes (cluster distribuido)
Complejidad operacional Baja (bien conocido, herramientas maduras) Alta (monitoreo distribuido, sharding)

Cuándo Elegir SQL

  1. Facturación, contabilidad, SUNAT compliance:

    Necesitas garantía de que datos nunca se pierden, nunca se duplican. ACID es obligatorio. SQL es estándar.

  2. Transacciones con múltiples tablas:

    Transferencia bancaria: débito cuenta A y crédito cuenta B. Si falla una, ambas fallan. Rollback automático.

  3. Reportes y análisis complejos:

    SELECT ... JOIN ... GROUP BY ... HAVING. SQL es poderoso para esto. NoSQL requiere pre-computación.

  4. Relaciones entre datos claras:

    Clientes ↔ Pedidos ↔ Líneas de pedido ↔ Inventario. Estructura clara. Join es la solución.

  5. Datos estructurados y estables:

    Schema no cambia cada semana. Registros de empleados, productos, cuentas bancarias.

  6. Volumen pequeño a medio (< 1TB):

    SQL escala bien vertical. No necesitas distribuir en 100 máquinas.

Cuándo Elegir NoSQL

  1. Datos no estructurados o flexible:

    Cada documento es diferente. Logs, eventos, redes sociales. MongoDB encaja perfectamente.

  2. Escala masiva (millones de inserciones/segundo):

    IoT sensors enviando datos. Logs de aplicación. Cassandra y ClickHouse son candidatos.

  3. Lecturas en tiempo real de alto volumen:

    Feed de redes sociales, recomendaciones. Redis es perfecto (< 1 ms latencia).

  4. Disponibilidad > Consistencia:

    Si el nodo 1 falla, otros responden. Tolerancia a particiciones de red. BASE model.

  5. Búsqueda full-text rápida:

    Elasticsearch: buscar "notebooks baratos" en millones de productos en < 100 ms.

  6. Cache distribuido:

    Redis para sesiones, tokens, leaderboards. Acceso en < 5 ms.

Casos de Uso Reales para PYMES Peruanas

E-commerce (Shopify + Custom):

  • SQL: Productos, pedidos, facturas SUNAT, inventario.
  • NoSQL: Logs, eventos de usuario (click, view), recomendaciones.
  • Arquitectura: PostgreSQL + Elasticsearch + Redis.

ERP Exportador Peruano:

  • SQL: Compras, ventas, facturas, comprobantes de pago (críticos SUNAT).
  • NoSQL: Documentos escaneados, emails, historial de chat con clientes.
  • Arquitectura: PostgreSQL + MongoDB.

Aplicación de Reservas (Hotel, SPA):

  • SQL: Reservas, clientes, habitaciones, tarifas.
  • NoSQL: Reviews, fotos, preferencias de cliente.
  • Arquitectura: MySQL + Firebase (NoSQL cloud).

Análisis de Datos / BI:

  • SQL: Data warehouse (PostgreSQL con muchos índices).
  • NoSQL: ClickHouse para queries ultra-rápidos (OLAP).
  • Arquitectura: PostgreSQL → ETL → ClickHouse → Grafana.

Tipos de NoSQL

1. Document Store (MongoDB, Firebase):

  • Datos en JSON-like documents.
  • Mejor para: Logs, eventos, perfiles de usuario flexible.
  • Costo: MongoDB Atlas S/ 500-3,000/mes. Firebase S/ 0-2,000/mes (pago por uso).

2. Key-Value Store (Redis, Memcached):

  • Datos como clave → valor. Todo en RAM.
  • Mejor para: Cache, sesiones, leaderboards, rate limiting.
  • Costo: Redis Cloud S/ 200-1,500/mes. On-premise: servidor S/ 1,500/mes.

3. Search Engine (Elasticsearch, Solr):

  • Indexa y busca texto muy rápido.
  • Mejor para: Búsqueda full-text, logs aggregation, analytics.
  • Costo: Elasticsearch Cloud S/ 1,000-10,000/mes. On-premise: S/ 2,000-5,000/mes.

4. Time-Series (InfluxDB, Prometheus):

  • Optimizado para datos con timestamp (métricas).
  • Mejor para: Monitoreo, IoT sensors, gráficas de performance.
  • Costo: InfluxDB Cloud S/ 500-3,000/mes. On-premise: gratis.

5. Graph (Neo4j):

  • Relaciones como first-class citizens.
  • Mejor para: Redes sociales, recomendaciones, "amigos de amigos".
  • Costo: Neo4j AuraDB S/ 1,500-8,000/mes. On-premise: S/ 3,000-10,000/mes.

Costos de Hosting en Perú (Soles)

SQL:

  • PostgreSQL en Render/Railway: S/ 100-500/mes.
  • AWS RDS PostgreSQL (t3.small): S/ 1,500-2,500/mes.
  • Azure Database: S/ 1,000-3,000/mes.
  • Google Cloud SQL: S/ 1,200-2,800/mes.
  • On-premise (servidor dedicado): S/ 2,000-4,000/mes.

NoSQL Cloud:

  • MongoDB Atlas (shared cluster): S/ 200-500/mes.
  • Firebase Realtime: S/ 0-2,000/mes (pago por uso).
  • Elasticsearch Cloud: S/ 1,000-10,000/mes.
  • Redis Cloud: S/ 200-1,500/mes.

Caso de Estudio: Marketplace Peruano (Viajes)

Situación: Plataforma de reserva de paquetes turísticos. 50K usuarios, 10K proveedores, 100K búsquedas/día.

Decisión inicial (ERROR): Todo en MongoDB ("moderno y escalable")

  • Problemas: Reportes lentos, facturación incorrecta, transacciones fallidas.
  • Causa: NoSQL no es bueno para datos financieros complejos.

Rediseño (CORRECTO): SQL + NoSQL híbrido

  • PostgreSQL: Usuarios, reservas, pagos, facturas (datos críticos).
  • Elasticsearch: Índice de paquetes turísticos para búsquedas rápidas.
  • Redis: Cache de búsquedas populares, disponibilidad de seats.
  • MongoDB: Reviews, fotos, comentarios (datos flexible).

Resultados:

  • Búsquedas: 200 ms → 50 ms (4x más rápido).
  • Transacciones: Errores ocasionales → 0 errores (ACID en PostgreSQL).
  • Reportes: Manual (30 min) → Automático (2 min, con BI).
  • Costo total: S/ 8,500/mes (PostgreSQL + Elasticsearch + Redis + hosting).

Checklist: ¿Qué BD Elegir?

Responde estas preguntas:
¿Necesito garantía ACID (facturación, dinero)? SÍ → SQL | NO → Considera NoSQL
¿Haré queries complejas (JOIN, GROUP BY)? SÍ → SQL | NO → NoSQL puede funcionar
¿Mis datos tienen relaciones claras? SÍ → SQL | NO → NoSQL es mejor
¿Espero > 1M escrituras/segundo? SÍ → NoSQL | NO → SQL está bien
¿Mi schema cambia cada mes? SÍ → NoSQL | NO → SQL está bien
¿Necesito búsqueda full-text rápida? SÍ → Elasticsearch | NO → SQL + índices
¿Necesito datos en cache (< 5ms)? SÍ → Redis | NO → BD normal
3+ SQL → Usa PostgreSQL. 3+ NoSQL → Usa arquitectura híbrida. Incierto → Empieza con SQL, agrega NoSQL después.

Errores Comunes a Evitar

1. Elegir NoSQL porque "es moderno":

NoSQL no es mejor. Es diferente. Para facturación, SQL siempre.

2. Todo en una sola BD:

SQL para datos críticos, NoSQL para datos secundarios. Hybrid es normal en 2026.

3. Ignorar backups/replicación:

Ambas requieren. SQL: WAL + replicación. NoSQL: sharding + replicas.

4. No indexar correctamente:

Sin índices, queries lentas. Ambas necesitan tuning.

5. Asumir NoSQL es más barato:

Cluster distribuido cuesta más que servidor SQL único. Compara costos totales.

Migración Entre BDs: Cuando Es Necesario

Si elegiste mal, migrar es doloroso pero posible:

  • SQL → SQL: Relativamente fácil (ambas entienden relaciones).
  • SQL → NoSQL: Denormalizas datos. Posible pero requiere diseño.
  • NoSQL → SQL: Difícil. Necesitas definir schema retroactivamente.

Ejemplo: Migración NoSQL → SQL toma 2-4 semanas + refactoring de código.

Conclusión

SQL es la opción segura para PYMES peruanas. Razones:

  • SUNAT compliance: datos financieros requieren ACID.
  • Reportes: contabilidad, flujo de caja, auditorías regulatorias.
  • Relaciones claras: clientes, pedidos, productos.
  • Bien conocido: cualquier developer lo entiende.
  • Barato: PostgreSQL open-source, hospedaje desde S/ 100/mes.

Agrega NoSQL cuando:

  • Necesitas búsqueda ultra-rápida (Elasticsearch).
  • Tienes caché distribuido (Redis).
  • Datos secundarios flexible (MongoDB).

Regla de oro: Empieza con SQL. Si crece y necesitas NoSQL, migrа porcion específica. No hagas "big bang" NoSQL desde el inicio.

En TSDFACT diseñamos arquitecturas de datos para PYMES: desde pequeño SQL hasta sistemas híbridos complejos. Consultemos tu caso sin costo.

Diseñar mi arquitectura BD Volver al blog