- La mayoría de las aplicaciones web necesitan almacenamiento persistente de datos, así que al crear una aplicación nueva conviene elegir
Postgres por defecto.
¿Por qué no sqlite?
sqlite es una buena base de datos, pero los datos se guardan en un solo archivo.- Eso significa que la aplicación solo se ejecuta en una sola máquina.
- Es adecuada para apps de escritorio o móviles, pero puede no serlo para sitios web.
- Hay casos exitosos de uso de sqlite en sitios web, pero en general son casos donde construyeron y operaron su propia infraestructura y servidores.
- Puede que tengas que renunciar a los respaldos automáticos de base de datos que ofrece la plataforma y a la posibilidad de configurar varios servidores de aplicación.
¿Por qué no DynamoDB, Cassandra o MongoDB?
- Estas bases de datos ofrecen un rendimiento excelente, pero vienen con muchos supuestos:
- Debes saber con precisión qué trabajo hará la aplicación y cuáles serán sus patrones de acceso.
- Necesitas escalar a un volumen de datos muy grande.
- Puedes renunciar a parte de la consistencia.
- Estas bases de datos funcionan de forma parecida a mapas hash distribuidos, así que el conocimiento de los patrones de consulta debe reflejarse en cómo se almacenan los datos.
- Si cambia el patrón de acceso (consulta), puede que tengas que reprocesar todos los datos.
- En una base de datos relacional puedes agregar índices fácilmente para resolver consultas, pero en una base de datos NoSQL eso es más difícil.
- No son adecuadas para consultas analíticas.
- Si un universitario o un desarrollador junior usa MongoDB, probablemente va a necesitar ayuda.
¿Por qué no Valkey?
- Esta base de datos, conocida como
Redis, es muy famosa por ser un caché muy eficiente.
- Puede usarse como base de datos principal, pero tiene problemas como estos:
- Guarda todos los datos en RAM, así que es rápida, pero la capacidad de la RAM es limitada.
- Requiere concesiones en el modelado de datos.
¿Por qué no Datomic?
- Si ya conoces esto, te mereces una "estrella dorada".
Datomic es una base de datos NoSQL relacional que no tiene el problema del "diseño por adelantado (Up-front Design)" y cuenta con algunas propiedades elegantes.
- Guarda los datos como pares EAVT (entity-attribute-value-time) en vez de tablas y usa índices genéricos.
- Al escribir consultas no hace falta coordinarse con el autor. Basta con consultar la base de datos en el "momento actual" de un instante dado. Los datos nuevos, e incluso las eliminaciones (o "retractions"), en realidad no borran los datos anteriores.
- Pero tiene varias desventajas:
- Solo funciona en lenguajes de la JVM.
- Fuera de
Clojure, su API no es buena.
- Los mensajes de error causados por consultas mal estructuradas son muy poco amigables.
- Carece de algo equivalente al ecosistema de herramientas de SQL, así que faltan herramientas.
¿Por qué no XTDB?
- Los usuarios de Clojure crean muchas bases de datos.
- Se parece a
Datomic, pero tiene estas características:
- Ofrece una API HTTP, así que no depende de la JVM.
- Permite consultar en dos ejes: "tiempo del sistema" y "tiempo de validez".
- Soporta una API SQL.
- Pero el mayor problema es que sigue siendo "muy nuevo". La API SQL salió el año pasado y recientemente cambió todo su modelo de almacenamiento.
- ¿Seguirá existiendo dentro de 10 años? Su soporte a largo plazo es incierto.
¿Por qué no Kafka?
Kafka es un log "append-only" excelente y sirve muy bien para procesar datos a escala de TB.- Si quieres hacer trabajo del tipo event sourcing con datos que llegan desde varios servicios administrados por varios equipos, funciona sorprendentemente bien.
- Sin embargo:
- A pequeña escala, una tabla de
Postgres puede reemplazarlo perfectamente.
- Crear consumidores de Kafka es más propenso a errores de lo que parece. Al final, tienes que rastrear tu propia posición dentro del log.
- Tienes que administrar infraestructura adicional.
¿Por qué no ElasticSearch?
- Si la búsqueda de datos es una función principal del producto, ElasticSearch es una opción adecuada.
- Tienes que hacer ETL de los datos y gestionar todo el proceso, pero ElasticSearch fue hecho para búsqueda y hace bien la búsqueda.
- Pero si la búsqueda no es la función principal, la búsqueda de texto integrada de
Postgres suele ser suficiente.
- Más adelante puedes agregar un motor de búsqueda dedicado.
¿Por qué no MSSQL u Oracle DB?
- La verdadera pregunta que debes hacerte es: "¿Vale lo que cuesta?"
- Debes considerar no solo el costo de la licencia, sino también el costo del lock-in.
- Si guardas tus datos en Oracle, le pagarás a Oracle para siempre y tendrás que seguir capacitando desarrolladores.
- Tendrás que elegir para siempre entre funciones empresariales y tu cartera.
- A menos que realmente necesites una función específica, es mejor evitarlo.
- No lo uses salvo que tenga una función decisiva sin la cual no puedas vivir, en especial en el caso de MSSQL.
¿Por qué no MySQL?
- En esta parte necesito un poco de ayuda del lector.
MySQL pertenece a Oracle, y algunas funciones están bloqueadas en la edición enterprise.
- Claro,
MySQL se ha usado durante mucho tiempo y existe una edición gratuita muy extendida.
- Creo que
Postgres es una mejor opción, pero necesito más información adicional sobre MySQL.
¿Por qué no una base de datos vectorial de IA?
- La mayoría de las bases de datos vectoriales de IA son tecnologías nuevas, así que usarlas implica riesgo.
- Conviene tener cautela con negocios basados en la burbuja de la IA.
- Incluso si tu negocio es otra estafa de IA, probablemente con algo como
import openai te bastará.
¿Por qué no Google Sheets?
- No tiene una desventaja particular; si lo necesitas, puedes usarlo.
18 comentarios
Firestore...
Este tipo de artículos que afirman eso tan tajantemente, por lo general, son errores que cometen los juniors...
En lugar de eso, les daré una CVS adorable
zzz
Para obtener buena información, hay que llamar la atención… por alguna razón me acordé de esa broma jaja.
En cualquier caso, como PostgreSQL suele ser lo primero que usan la mayoría de los desarrolladores backend…
Creo que Postgres es una mejor opción, pero necesito más información adicional sobre MySQL
jajaja;;;;
El verdadero problema de MySQL Enterprise no es la licencia, sino que incluso para quienes pagan, el soporte cuando ocurre una caída es realmente una porquería.
Antes, cuando se dañó el índice de MySQL y no arrancaba, aunque pedimos soporte, Oracle solo dijo que si abríamos un ticket de soporte nos darían atención por teléfono, y eso fue todo.
Al final, el cliente dijo que así no servía, así que tuvimos que resolverlo nosotros.
En vez de confiar en Oracle y usar Enterprise, lo mejor es lo gratis..
¿Por qué no mariadb, impala, hive o kudu?
Las funciones enterprise de MySQL son cosas que realmente no hacen falta, como su propio pool de conexiones..
Si de verdad es enterprise, en vez de usar esto es más efectivo instalar un SQL proxy al frente para balancear la carga.
Me gusta PgSQL, pero que hablen así de MySQL sin siquiera investigarlo.. jajaja
Simplemente usa MySQL…
¿Y MariaDB?
Parece una publicación que podría generar un debate enorme...
La razón para usar SQLite es que es simple y, para una escala razonable, simplemente funciona bien.
Puedes implementarlo primero con SQLite y, si más adelante hace falta, pasar a Postgres sin mucha dificultad.
Otro artículo de elogio a Postgres que aparece cada tanto. ¡Ahora simplemente disfrútenlo!
Simplemente usen Postgres para todo
Con PostgreSQL es suficiente
¿Desde cuándo Postgres se volvió genial?
Opiniones de Hacker News
Hay muchas opiniones negativas sobre MongoDB, pero la mayoría están mal informadas
Ventajas de SQLite
Señalar defectos técnicos no tiene mucho sentido
Motivos para migrar de MySQL a Postgres
Falta soporte de tablas temporales en Postgres
No entiendo por qué usar SQLite
Disculpas por haber mencionado mal el nombre de Rick Houlihan
Lo importante es usar lo que conoces y desplegar lo que sea útil
MySQL es como Javascript
Postgres tiene más herramientas para mantener la consistencia de los datos
=> ¿Podrías dar algún ejemplo?
Una desventaja de SQLite frente a Postgres es que no soporta
schema. Cuando hay decenas de tablas o más, es más limpio diseñarlas separándolas porschema, pero como SQLite no permite eso, termina siendo necesario meter toda la distinción en el nombre de las tablas.