Neki – Postgres fragmentado

Qué es Neki y su posicionamiento

• Se describe como un sistema de PostgreSQL fragmentado con una capa de enrutamiento que añade indirección entre las aplicaciones y los fragmentos de Postgres.
• Se comercializa como “parecido a Vitess, pero para Postgres”, construido por ingenieros con experiencia en Vitess, pero se afirma que es una implementación desde cero para Postgres.
• Está pensado para gestionar redistribución de fragmentos en línea y cargas de trabajo a gran escala; solo funciona como un servicio gestionado del proveedor, no “en cualquier lugar”.

Documentación, mensaje y marketing

• A muchos lectores les costó entender “qué es Neki” a partir del blog de lanzamiento; la página de destino se vio como más clara.
• Algunos sintieron que la publicación carecía de una descripción concisa de nivel superior y de garantías de consistencia; más tarde se añadieron ediciones con una sección “Qué es Neki” y, finalmente, se redirigió a la página de marketing.
• El diseño y la marca recibieron elogios, pero algunos siguieron encontrando poco claro el modelo del producto (totalmente gestionado frente a autogestionado).
• Unos pocos comentarios señalaron marketing coordinado (anuncios, múltiples publicaciones en HN).

Fragmentación, transacciones y consistencia

• Preguntas sobre:
  • Cómo funcionan las uniones y transacciones entre fragmentos.
  • Si se admiten claves foráneas y restricciones entre fragmentos.
  • Modelo de consistencia (fuerte frente a eventual, opciones de lectura después de escritura, retardo de réplicas).
• Los representantes dicen:
  • Existen transacciones entre fragmentos, pero aún no con 2PC totalmente atómico; eso está en progreso.
  • El enrutador no comparte código con Postgres.
• Varios piden una página clara de garantías y diagramas de arquitectura/C2; algunos calificaron la documentación actual de “similar a IA” o vaga.

Carencias de funciones y áreas poco claras

• Parece que faltan claves foráneas y restricciones entre fragmentos; algunos comparan esto con versiones antiguas de otras bases de datos distribuidas.
• No está claro cómo se manejan tablas muy grandes (p. ej., más de 8 mil millones de filas) y si una sola tabla puede abarcar varios fragmentos.
• El comportamiento de consistencia y los escenarios de fallo no están completamente documentados en el hilo.

Debate entre código abierto y propietario

• Varios comentaristas se preocupan mucho por el código abierto por seguridad a largo plazo y riesgo de proveedor; algunos dicen que no les interesa el código cerrado.
• La empresa está “indecisa” sobre abrir el código de Neki, pero enfatiza que necesita protección frente a que grandes proveedores de nube repliqueen el servicio.
• Algunos señalan la ironía de que la empresa se construya sobre un proyecto de código abierto mientras mantiene Neki cerrado.

Comparaciones con otros sistemas

• Se hicieron comparaciones con: Citus, Multigres, pgdog, la oferta de Supabase, Aurora, Cloud SQL, Spanner, MySQL de Vitess/PlanetScale, MariaDB Galera, TiDB.
• Los representantes subrayan que Neki ya admite fragmentación y redistribución de fragmentos en línea, mientras afirman que algunos competidores aún no tienen una fragmentación madura.
• Proyectos competidores de código abierto destacan las ventajas de poder autohospedarse y no ser propietarios.

Percepción de la cultura de la empresa y el tono

• Hay una discusión paralela importante sobre el comportamiento público del CEO y sus publicaciones criticando a competidores.
• Algunos encuentran el estilo agresivo y sarcástico entretenido o refrescantemente honesto; otros lo ven poco profesional, desagradable o como una razón para evitar el producto.
• Debate sobre si la defensa confrontativa de un modelo comercial/de código abierto parcial está justificada o es contraproducente.