Migración de E-commerce: De Strapi y Neon a Next.js + Payload CMS v3 y Turso

1. El Reto de la Infraestructura Tradicional

El e-commerce B2B y catálogo corporativo de DP-FIRE Chile (los representantes oficiales de Kidde Fire Systems en Chile) requería un backend robusto para la gestión de productos y cotizaciones. Inicialmente, la arquitectura constaba de una aplicación cliente en Next.js conectada a un servidor Strapi CMS independiente en Render (con un costo fijo de $25.00 USD al mes debido a sus requerimientos de memoria) y una base de datos PostgreSQL en Neon (por un valor mensual de $14.00 USD).

Con un gasto total de $39.00 USD mensuales solo para el módulo del e-commerce, el objetivo de la gerencia era claro: minimizar los costos de infraestructura fija sin comprometer el rendimiento ni la autonomía del equipo para actualizar el catálogo.

2. Decisiones Clave de Arquitectura

Para solucionar este reto financiero y de rendimiento, se reestructuró el sistema por completo bajo un enfoque acoplado y bases de datos serverless en el Edge.

graph LR
    subgraph "ARQUITECTURA PREVIA (E-commerce)"
        NextJS_Prev[Next.js App] -->|REST API| Strapi[Strapi CMS on Render]
        Strapi -->|SQL Queries| Neon[Neon PostgreSQL Database]
    end

    subgraph "ARQUITECTURA ACTUAL (E-commerce)"
        NextJS_New[Next.js + Payload CMS v3] -->|Local DB Call| Turso[Turso libSQL Database Edge]
    end

2.1. De Strapi a Payload CMS v3 (Arquitectura Acoplada)

Strapi, en arquitecturas tradicionales desacopladas (Headless), requiere correr en un servidor de Node de fondo de forma continua las 24 horas del día. En instancias gratuitas o de bajo costo (como Render), la baja de actividad causa que el servidor entre en reposo, generando latencias de carga inaceptables (frío de arranque) para los clientes, lo que obligaba a pagar una instancia dedicada de $25.00 USD mensuales.

La Solución: Reemplazamos Strapi por Payload CMS v3. A partir de su versión 3, Payload CMS se integra de manera acoplada directamente dentro del framework de Next.js como una ruta nativa (app/(app)/api/...). Esto nos permite:

• Alojarse dentro de la misma infraestructura del frontend (en Railway, compartiendo el entorno).
• Eliminar el coste del hosting dedicado para el CMS a $0 USD.
• Beneficiarse de llamadas de base de datos directas locales, mejorando los tiempos de respuesta.

2.2. De Neon (PostgreSQL) a Turso (SQLite en el Edge)

Neon cobraba un plan mínimo de $14.00 USD mensuales por almacenamiento y cómputo de base de datos. Al cambiar a Payload CMS v3, aprovechamos su soporte nativo para bases de datos SQLite y libSQL a través del adaptador @payloadcms/db-sqlite.

La Solución: Migramos los datos a Turso, una base de datos relacional basada en libSQL optimizada para el Edge.

• Turso distribuye copias de la base de datos de manera global en ubicaciones del Edge muy cercanas a los usuarios, garantizando consultas ultrarrápidas.
• Ofrece una generosa capa gratuita que cubre hasta 500 bases de datos y 9GB de almacenamiento.
• Costo fijo mensual: $0.00 USD.

3. Resultados y Retorno de Inversión

La migración a esta arquitectura moderna no solo mejoró el rendimiento y las velocidades de carga del sitio, sino que logró un impacto financiero directo:

• Coste mensual previo: $39.00 USD (E-commerce por separado)
• Coste mensual actual: $0.00 USD adicionales (alojado dentro del costo compartido de Railway por uso activo).
• Ahorro neto: $468.00 USD anuales solo en la sección del e-commerce.

Esto demuestra cómo el uso estratégico de tecnologías Serverless en el Edge y de frameworks integrados como Payload CMS v3 y Next.js permite a las empresas emergentes y medianas optimizar sus flujos de caja reduciendo los costes fijos de mantenimiento.