Blog
Por qué Go y Postgres para casi todo
Nuestro stack default para la mayoría de proyectos, y cuándo no usarlo.
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.
¿Necesitás revisar una decisión técnica?
Traenos el sistema, la restricción y el tradeoff. Te ayudamos a elegir el camino con menos arrastre a largo plazo.