No existe la base de datos "mejor". Existe la base de datos adecuada para cada tipo de problema. El error más común en proyectos de software es elegir la base de datos que el desarrollador ya conoce en lugar de la que mejor resuelve el problema del negocio.
Este artículo no es un debate SQL vs. NoSQL es una guía de cuándo usar cada opción con ejemplos reales del sector fintech.
PostgreSQL: la base de datos por defecto para sistemas financieros
En Ab4cus, PostgreSQL es el estándar para todos los datos de negocio con requerimientos de integridad transaccional. No porque sea el único camino, sino porque para el 80% de los casos en fintech, es la herramienta correcta.
Por qué PostgreSQL gana en fintech:
- ACID compliance completo: una transferencia bancaria que debita de cuenta A y acredita en cuenta B ocurre completa o no ocurre nunca a medias. PostgreSQL garantiza esto con transacciones reales.
- Row Level Security (RLS): el aislamiento de datos entre clientes a nivel de base de datos, no solo de aplicación. En un SaaS multi-tenant como BAS, RLS garantiza que ningún query pueda cruzar los datos de dos instituciones.
- Soporte nativo de JSON, arrays y extensiones: pgcrypto para cifrado, pg_trgm para búsqueda difusa de nombres en listas de sanciones, PostGIS para datos geoespaciales todo sin cambiar de base de datos.
- Flyway para migraciones versionadas: cada cambio de schema es un archivo SQL versionado, reproducible en cualquier ambiente, reversible en caso de error.
Cuándo PostgreSQL no es suficiente solo: cuando necesitas caché de alta velocidad, búsqueda de texto completo a escala masiva, o datos de series temporales de alta frecuencia. Ahí es donde entran las otras herramientas.
Redis: velocidad antes que todo
Redis es una base de datos en memoria los datos viven en RAM, no en disco. El resultado: latencias de menos de 1 milisegundo para operaciones de lectura y escritura.
Casos de uso reales en fintech:
- Caché de sesiones: guardar los datos del usuario autenticado para no ir a PostgreSQL en cada request la sesión se lee de Redis en <1ms
- Rate limiting: controlar cuántas veces puede un usuario intentar autenticarse en 15 minutos un contador en Redis con TTL es la forma más eficiente
- Cola de trabajo con BullMQ: los jobs de procesamiento de KYC, notificaciones push y reportes regulatorios se encolan en Redis y se procesan asincrónicamente
- Cache de listas de sanciones: las listas OFAC y ONU se cargan en Redis al inicio del día para que el screening de cada transacción sea instantáneo sin ir a la base de datos
En el stack de Ab4cus, Redis (via ioredis en NestJS) maneja caché, rate limiting y las colas de BullMQ. No almacena datos de negocio eso es responsabilidad de PostgreSQL.
MongoDB: documentos cuando los schemas cambian
MongoDB almacena documentos JSON sin schema fijo. Esto es una ventaja cuando los datos tienen estructura variable y una desventaja cuando necesitas integridad relacional.
Cuándo MongoDB tiene sentido:
- Logs de eventos con estructura variable (cada tipo de evento tiene campos distintos)
- Catálogos de productos con atributos dinámicos (un producto electrónico tiene specs diferentes a un producto de ropa)
- Sistemas de contenido donde los documentos se recuperan completos y raramente se hacen JOINs complejos
Por qué no en transacciones financieras: MongoDB tiene soporte de transacciones ACID desde la versión 4.0, pero es más complejo de configurar correctamente y tiene mayor overhead que PostgreSQL para operaciones transaccionales. Para datos financieros donde la integridad es no-negociable, PostgreSQL es más robusto.
Cassandra: big data y series temporales a escala masiva
Apache Cassandra está diseñada para escrituras masivas con alta disponibilidad geográfica. Es la base de datos detrás de Netflix, Instagram y Discord para casos de escala extrema.
Cuándo considerar Cassandra en fintech:
- Almacenamiento de logs de auditoría con millones de escrituras por día (inmutables, append-only)
- Series temporales de métricas de fraude a escala de millones de transacciones por hora
- Sistemas multi-región donde la disponibilidad geográfica es más importante que la consistencia fuerte
Para la mayoría de proyectos fintech en LATAM que no están en la escala de Netflix, Cassandra es prematura. PostgreSQL con particionamiento de tablas maneja decenas de millones de registros sin problemas.
La arquitectura de datos de Ab4cus en la práctica
| Tipo de dato | Herramienta | Razón |
|---|---|---|
| Cuentas, usuarios, transacciones | PostgreSQL | ACID, RLS, integridad referencial |
| Sesiones, caché, rate limiting | Redis | Latencia sub-ms, TTL nativo |
| Colas de procesamiento asíncrono | Redis + BullMQ | Retry automático, prioridades, monitoreo |
| Datos mobile offline | SQLite + Drizzle | Funcionalidad sin conexión, sync posterior |
| Archivos KYC (PDFs, fotos) | Cloudflare R2 | Object storage sin egress fees |
→ Calcular el costo de un sistema con arquitectura de datos correcta
0 Comentarios