Disclaimer
Eu entendo que quando se está fazendo um MVP, onde a idéia é tirar do papel para o mercado o mais rápido possível, qualquer stack que você já domina quase sempre é o caminho mais otimizado. Entretanto, tem algumas tecnologias que de fato deixam o processo menos dolorido.
Aqui eu vou assumir que o MVP em questão é uma aplicação web, já que estamos falando de stacks.
Por quê go (golang) para o backend
Go é uma linguagem espartana - simples e direta - bastante poderosa. Em performance é comparável com Java e outras linguagens com GC que já estão consolidadas no mercado faz bastante tempo, mas estou divagando, performance raramente é importante em MVPs.
A maior vantagem do Go é que ele compila - e muito rápido - diretamente para um binário pronto para ser executado pela máquina alvo (UNIX, Linux, e Windows). Esse binário é independente de depêndencias externas, como ter uma runtime ou bibliotecas que é o caso de Java e NodeJS, isso simplifica bastante o setup dos servidores, ele precisa somente executar o binário gerado pelo compilador e sua aplicação já está estará funcionando.
Também já vem incluido uma biblioteca nativa para lidar com arquivos de de templates HTML, isso possibilita gerar páginas renderizadas no servidor, algo parecido com o que o PHP, JSP no Java e Razor no .net fazem, se usar um framework javascript para renderizar sua aplicação não for uma necessidade para seu MVP, pode ser uma boa opção.
Persistência
Aqui temos várias opções, a primeira e mais óbvia são bancos relacionais tradicionais (postgres, mysql, etc.) e sendo bem honesto acho que qualquer um serve. Ja não é pratica tão comum aplicações novas aplicações usarem stored function/procedures e manterem lógica de negócio dentro de objetos no banco de dados, o que faria ser necessário casar com algum vendor específico, e se o MVP em questão não depende de uma base de dados legada, usa o que for mais barato no seu cloud provider de escolha.
E falando em preço, um banco relacional provávelmente é opção mais cara, já que é basicamente um servidor que vai ficar ligado 24/7, não escala sozinho e quando escala geralmente é pra cima.
Tirando a questão de custos, os bancos relacionais tem um ótima experiência para os desenvolvedores, toda linguagem praticamenet vai ter uma biblioteca ORM (GORM, no go, por exemplo) e há praticas consolidadas para gerenciamento dos schemas como migrations e caracteristicas que ACID que garante que as transações são executadas e com consistência imediata.
Se você não está disposto a fazer o investimento em um banco relacional, há opções como DynamoDB da AWS que você é cobrado só pelas requisições realizadas e não pelo servidor do banco de dados. A disvantagem desse tipo de solução é a mesma de qualquer banco NoSQL, consistência eventual e por schemaless é mais difícil garantir a consistência dos dados. A AWS provê um SDK para as principais linguagens de programação, go é uma delas.
Renderização da páginas
Meh, a ultima vez que trabalhei com frontend foi na época do AngularJS 1.5 que agora já está praticamente morto e enterrado. Então o que vou escrever aqui tem mais a ver com minhas limitações ao desenvolver aplicações para o browser.
Acho os frameworks populares do mercado como React, Angular e Vue ótimos, mas com uma curva de aprendizado muito grande que atrapalharia ao tentar executar um MVP (no meu caso).
Optaria por um framework mais enxuto como o Svelte cominado com framework de CSS como tailwind, qualquer coisa que me deixe mais produtivo do que escrever JS e CSS vanilla.
Tem um video interessante do ótimo canal Fireship no YouTube onde ele implementa a mesma aplicação em 10 frameworks diferentes para referência: