¿Las bases de datos noSQL o relacionales (SQL) son mejores para las startups de finTech?

La tecnología de base de datos correcta para su inicio depende de su caso de uso, en lugar de la industria en la que opera su inicio. Alejándose de la decisión relacional NoSQL vs, hay factores adicionales que debe considerar:

  • Autohospedado frente a un servicio: si tiene un equipo relativamente pequeño, tiene sentido usar un servicio (como Amazon RDS o DynamoDB). El proveedor de servicios se asegurará de que los servidores se actualicen con las últimas actualizaciones de seguridad, que se realicen copias de seguridad, etc.
  • ¿Con qué está familiarizado tu equipo? Si recién está comenzando, su pequeño equipo de ingeniería tiene algunos años de experiencia con bases de datos relacionales, digamos específicamente con MySQL, y desea minimizar su tiempo de comercialización; recomendaría comenzar con eso (a menos que sepa con certeza vamos a golpear una pared). Siempre puede cambiar a una solución de almacenamiento diferente en el futuro.
  • Copias de seguridad y recuperación: ¿su solución de base de datos le permite recuperar la base de datos en cualquier momento? Imagine que uno de sus servidores comienza a escribir basura en la base de datos, o si por error dejó caer una tabla y desea recuperar el estado anterior. Una de las cosas que me gustan de RDS es que hacen que sea muy fácil restaurar el estado de su base de datos en cualquier momento. Te deseo que nunca lo necesites, pero es genial que esté allí. También habla del punto de servicio alojado en lugar de uno mismo: cuando lo ejecuta usted mismo, debe preocuparse por las copias de seguridad.
  • Cifrado: sus clientes y socios (especialmente en FinTech) a menudo requerirán que sus datos se cifren en reposo y en tránsito. Al elegir una solución de base de datos, deberá verificar esto.

Como otros han mencionado, todo lo demás es igual: la decisión NoSQL vs relacional depende del tipo de datos que pretendes almacenar y de cómo planeas acceder a ellos, por lo que es imposible dar un argumento técnico convincente sin saber esto.

Finalmente, agregaré que con el reciente soporte de JSON en MySQL y Postgres, es bastante fácil almacenar documentos JSON completos e incluso indexarlos en campos, por lo que incluso puede tener un enfoque híbrido. En TrueAccord, recientemente escribimos en un blog sobre una capa de tienda de valor clave que creamos sobre Amazon Aurora.

Si tiene que preguntar, la respuesta es fácil: Postgres.

Si no tiene que preguntar, la respuesta sigue siendo bastante fácil: Postgres. Hay muy poco en fin-tech que Postgres sea incapaz de manejar, o muy probablemente, superior. Una ventaja importante es que relacional, SQL y Postgres son “probados y verdaderos”. Esto es ventajoso en general y particularmente en fin-tech. Es raro que un servicio de tecnología de punta cree su ventaja en el almacén de datos de fondo. Además, Postgres tiene capacidades que puede elegir usar, como integridad referencial, transacciones, números decimales, fechas y NoSQL.

Solo me apartaría de Postgres si tuviera una propuesta extremadamente convincente de por qué una alternativa claramente ayudaría a que mi producto final sea significativamente mejor.

Ni la amplia categoría de negocio ni la etapa del ciclo de vida de su empresa influyen en la aplicabilidad de alguna tecnología en particular al problema específico que necesita resolver. El inicio de FinTech no implica noSQL, ni lo contraindica.

Esta pregunta (y ciertamente no es única en mi experiencia) apesta a lo que yo llamo el nuevo síndrome del martillo . Potencialmente ha encontrado un nuevo martillo (noSQL) y está buscando cosas para acertar con él, ahora cada problema parece un clavo.

Si no sabe cuáles son las fortalezas y debilidades específicas de un esquema de persistencia de datos, ¿por qué está preseleccionado?

La pregunta más pertinente sería “¿qué tipo de datos está almacenando y cómo necesita o desea interactuar con ellos?”. Cuando haya determinado esto, puede comenzar a preguntar qué implementación podría ser más adecuada para su problema.

Olvídese de la publicidad y el zumbido de la industria. Olvídate de los productos que pueden estar disponibles. Comience con el problema que está tratando de resolver y avance desde allí.

SQL es mejor para datos estructurados. Nombre, dirección, ocupación, etc. NOSQL es mejor para datos no estructurados. Si escanea un montón de libros y luego raspa un montón más de páginas web y luego importa todos esos datos en una base de datos, las consultas NOSQL serían mejores para dar sentido a los datos que el SQL normal.

Fintech vinculado a las necesidades de las personas estaría mejor atendido por SQL. Fintech, donde está combinando una gran cantidad de datos no estructurados en busca de patrones, sería mejor con NoSQL.

Ni NoSQL ni las bases de datos relacionales son universalmente “mejores”. Cualquiera de los dos podría ser más adecuado según los requisitos específicos de su aplicación actual. Por lo tanto, su pregunta no se puede responder de manera confiable ya que no proporciona ningún detalle sobre lo que desea que haga esa base de datos …