Almacenamiento de Objetos Open Source

Elige el sistema que tu equipo pueda recuperar, actualizar y operar.

Respaldos, archivos de aplicaciones, datasets y modelos pueden compartir una interfaz S3 sin tener las mismas necesidades operativas. Estas son las opciones por las que empezaría y las condiciones que descartarían cada una.

Fuentes revisadas: 2026-09-05. Mi evaluación usa repositorios, versiones y documentación oficial, no un benchmark propio ni una certificación. Las pruebas de producción siguen siendo requisitos, no verificaciones ya realizadas.

Comparación de un vistazo

Aquí, Silo es el fork independiente de MinIO mantenido por PGSTY, no otro proyecto o servicio alojado con el mismo nombre.

La tabla compara el servidor open source, no la edición comercial de un proveedor. Los enlaces llevan a repositorios primarios; más abajo están las versiones y notas operativas. Ninguna fila es la ganadora universal.

Las licencias identifican el código del servidor revisado, no todas sus dependencias, componentes empaquetados u ofertas comerciales. El archivo COPYING de Ceph detalla la elección LGPL y sus excepciones por archivo. Revisa los términos de la distribución concreta al adoptarla; gratuito y open source no son sinónimos.

Empieza por la carga

Para una instalación nueva pequeña, compararía primero Garage y SeaweedFS. Si ya existe un sistema de archivos protegido, Versity Gateway es otra opción ligera: añade una interfaz S3, no una capa nueva de durabilidad. En un despliegue existente de MinIO, Silo plantea una vía de continuidad, pero hay que ensayar la actualización. Ceph, Ozone y Swift entran cuando su modelo de plataforma aporta valor, no solo porque ofrecen S3. RustFS sigue como release candidate y el repositorio original de MinIO community está archivado. Un endpoint compatible con S3 no promete todas las funciones de Amazon S3 ni el mismo comportamiento ante fallos.

• Una aplicación pequeña o varias ubicaciones independientes: empieza por Garage si sus permisos por bucket/clave y la ausencia de versionado encajan. Compara SeaweedFS si necesitas una interfaz de archivos o su modelo de filer. Un proceso sobre un disco resulta cómodo; no es alta disponibilidad.
• Respaldos que deben resistir borrados: no elijas por una subida exitosa. Exige las semánticas de Object Lock que soporte el cliente de backup, retención efectiva y un ensayo de restauración. Garage no encaja si Object Lock de S3 es obligatorio; las carencias S3 documentadas de Ozone también lo excluyen.
• Una instalación existente de MinIO: evalúa Silo sobre una copia recuperable con la versión de origen, topología, cifrado y clientes reales. Conserva una vía de recuperación verificada antes de cambiar cualquier binario en producción.
• Una plataforma de almacenamiento en cloud privada: empieza por Ceph RGW si el equipo ya opera Ceph o necesita sus otros servicios. Mantén Swift donde la organización ya conozca su operación. Ninguno justifica crear un equipo de almacenamiento para un bucket pequeño.
• Un data lake o una carga de IA: compara SeaweedFS y Ceph con los lectores, escritores y catálogo concretos. Añade Ozone en un entorno centrado en Hadoop. Un endpoint S3 no implementa por sí solo transacciones Iceberg, autorización del catálogo ni todo el flujo de datos de entrenamiento.

Otras capas y candidatos a seguir

Estos proyectos son relevantes para la decisión, pero no todos sustituyen un almacén de objetos distribuido. Separar las capas evita comparar una interfaz con el sistema responsable de conservar los bytes.

• Sistema de archivos existente: Versity Gateway 1.8.0 (Apache-2.0; publicado el 2026-09-04) traduce S3 a POSIX, ScoutFS, Azure u otro backend S3. Es mi candidato para una instalación pequeña si ya están resueltos el sistema de archivos, los respaldos y la recuperación. Su directorio de versiones POSIX no crea redundancia de discos ni un respaldo independiente.
• Plataformas especializadas de datos: NVIDIA AIStore (MIT) combina almacenamiento nativo, acceso a datos remotos y caché configurable para cargas intensivas. CubeFS 3.6.0 (Apache-2.0) combina interfaces de archivos y objetos distribuidos. Considéralos por el flujo de datos completo o la necesidad de archivos, no como respuesta predeterminada a un bucket pequeño. Fija la documentación que corresponde a la versión elegida.
• Interfaz S3 sobre otros backends: CloudServer 9.4.3 y S3Proxy 4.1.0 (Apache-2.0) conectan aplicaciones con almacenamiento existente. Evalúa por separado la durabilidad del backend y la compatibilidad del gateway; ejecutar una interfaz no equivale a operar toda la plataforma comercial de Scality.
• Desarrollo descartable y CI: local-s3 (MIT) está orientado expresamente a pruebas locales rápidas. Puede ser la opción más sencilla para ese propósito, no para durabilidad o replicación en producción.
• Candidatos tempranos: Alarik y FractalBits (Apache-2.0) se presentan como beta. Déjalos en evaluación; sus cifras de rendimiento o cantidad de funciones no sustituyen pruebas de recuperación, seguridad y actualización. Ser más nuevos no los coloca por encima de alternativas mantenidas.

Versiones y notas operativas

Abre un proyecto para consultar las fuentes que delimitan la recomendación. Una publicación reciente demuestra actividad, no fiabilidad para tu carga.

Antes de usar datos en cloud privada

Usa un entorno descartable con la topología y los clientes previstos. Define los criterios de aceptación antes de medir:

1. Compatibilidad: subir, listar, leer rangos, copiar y borrar; cargas multipart interrumpidas; URLs prefirmadas; checksums y escrituras condicionales. Prueba claves Unicode, metadatos y el cliente de backup o lakehouse. Un PutObject exitoso no valida toda la API S3.
2. Seguridad: deniega acceso anónimo y entre tenants, rota credenciales, aísla interfaces administrativas e internas y prueba TLS y recuperación de claves. Si aplica, prueba retención y legal hold con roles de aplicación y privilegiados. Alojar en privado no demuestra aislamiento ni cumplimiento.
3. Recuperación: pierde un disco, nodo y servicio de metadatos; llena la capacidad; interrumpe un enlace y restaura un despliegue limpio desde una copia independiente. Compara bytes, versiones, metadatos y permisos. Registra pérdida tolerable y tiempo de recuperación; replicar no basta para demostrarlo.
4. Actualización y salida: fija versiones de servidor/cliente y digests de artefactos. Ensaya la actualización soportada y una vía de recuperación si no se admite downgrade. Una copia puede omitir versiones, retención o políticas. No montes otro motor sobre discos activos sin soporte explícito.
5. Coste bajo fallos: mide tamaños reales de objetos, mezcla de solicitudes, concurrencia y latencias p95/p99 durante la reparación, no solo en estado estable. Cuenta capacidad útil tras réplicas/paridad, reserva libre, RAM, red, energía, respaldos independientes y las personas que atienden incidentes.

Si nadie se responsabiliza de esas pruebas y de la recuperación, un servicio gestionado es una referencia válida aunque autogestionarlo parezca más barato al principio. Revisa la comparación cuando una versión, el mantenimiento, un requisito S3 o una prueba de fallo cambien las opciones.