Blog
· backend · stack
Nuestro stack default para la mayoría de proyectos, y cuándo no usarlo.
Por qué Go y Postgres para casi todo
En Ferced empezamos casi todo proyecto nuevo con Go + Postgres. No es dogma; es el resultado de probar muchas combinaciones y encontrar la que más veces nos deja dormir tranquilos.
Razones concretas
- Binarios estáticos: deploy sin sorpresas. Un
go buildy listo. - Compilación rápida: feedback loop tight durante el build.
- Concurrencia simple: goroutines y channels son más fáciles de razonar que async/await.
- Postgres resuelve 80% de lo que la gente cree que necesita Redis, Elastic o Mongo.
Cuándo no lo usamos
- Frontends pesados de data visualization: React + TS queda mejor.
- ML serving con modelos grandes: Python + CUDA es la opción obvia.
- Prototipos throwaway: si sabemos que el proyecto no va a vivir más de un mes, elegimos lo que acelere el tirón — usualmente TypeScript full-stack.
El principio
El stack aburrido es el que escala sin rompernos la espalda.
Nada de esto es novedoso. Justamente por eso funciona.