Porque você em seus projetinhos, ainda usa PostgreSQL?

Depende muito, como sempre. Se o projeto vai escalar, o ideal seria usar PostgreSQL mesmo. Mas depende muito do quanto vai escalar. No geral um SQLite resolve quase todos os problemas.

Porém cuidado, para determinar qual é melhorar para cada situação é complexo. Uma feature a mais ou a menos já pode mudar muito o cenário. SQlite por exemplo não lida com concorrência tão bem quanto o PostgreSQL. Então mesmo que o projeto seja pequeno, mas depender altamente de uma concorrência, o ideal seria PostgreSQL.

Sobre o MySQL nunca cheguei a usar, e portanto não posso opinar sobre. Pouco vejo falando dele hoje em dia. Sei que antigamente dominava muito, hoje em dia eu já não sei mais. Vai ver muita gente ainda usa, a ferramenta seja boa, mas tenha uma bolha que nos prende a SQLite e PostgreSQL/MongoDB

boa noite, sr.

sim, tenho ido quase sempre de postgresql.
eu sinto que ocorrem diferentes hypes, e todos são normais.
às vezes, cada lado apenas quer ter o seu próprio lado, e tá tudo bem.

uma análise orientada a fundamentos e baseada em pré-requisitos é a mais madura decisão.

eu tinha uma tv box de 2GB de RAM já rodando armbian em um allwinner H3 (quad core @ 1.2GHz). eu a usaria para usar como servidor web de testes. por isso, simplesmente eu descartei o postgresql. não quis me preocupar com otimizações de RAM. simplesmente, o sqlite com um ORM seria o suficiente para mim. eu ainda ia rodar docker, e precisaria de cache com redis. é um projetinho, em um cenário em que recursos são críticos. eu só tinha 8GB de armazenamento NAND

para trabalhar em empresas, as quais já têm projetões os quais utilizam SGBDs intensivos em RAM de qualquer forma, considerando que muitos devs ainda vão candidatar-se a essas empresas, precisarei de ressaltar: é válido defender o uso de SGBDs nos projetinhos de aprendizados.

se eu estivesse lá em 2012, eu ainda escolheria o postgresql se eu: não soubesse como sqlite funciona; se eu não tivesse conhecimento sobre bancos de dados; se eu precisasse de outros tipos de ferramentas.

para um servidor de jogo 2D feito no rpg maker xp em 2015, faz todo sentido usar o sqlite.
se eu usasse o postgres para isso, sendo que na verdade eu usaria mysql porque esse o hype da época, eu sentiria tanta dificuldade OU ficaria tão pesados as rotinas e os serviços (meu hardware na época era fraco), que provavelmente eu redescobriria a existência do sqlite e a necessidade de usá-lo para hospedar numa VPS de 1 núcleo com 2GB de RAM com 100GB de HD (SAS? não sei se na época era).

Boa noite a todos

Eu não uso muito o postgres, não por ser ruim ou algo do tipo. Utilizo muito o mysql por ser a escolha padrão da minha stack (Laravel).

Se for um projeto com recursos limitados, como um app de celular, o sqlite é a melhor escolha, já que não preciso de um serviço de banco de dados rodando em segundo plano e seu custo de recursos é baixo, equivalente a ler um arquivo de texto.

Para projetos onde teríamos pouco acesso simultâneo, o sqlite da conta do recado.

Para projetos médios, o postgres tem ótima performance e o mysql/mariadb não ficam atrás de recursos e performance. Aí nesse caso o sqlite fica muito atrás por acesso simultâneo.

Agora, se sua empresa é grande e teremos um único banco de dados com muitas tabelas, aí terá que ir para um banco mais parado, com Oracle ou mssql server. Pois aí o postgres e o mysql dão conta mas já fica extremamente apertado para trabalhar.

Não existe bala de prata, mas sim analisar qual será o uso. Se algo para testes com poucos acessos vai de sqlite é seja feliz. Se precisar de acesso simultâneo, um mysql ou postgres já resolve. Se precisar de muitos dados, com muitos acessos, Oracle ou mssql server.

Sempre PostgreSQL, conheço outros mas PGSQL (ou o dialeto SQL do PostgreSQL) ainda continua sendo essencial para qualidade de vida, coisas como "SELECT DISTINCT ON (coluna)" não tem alternativa para aplicações locais ainda arrisco um SQLite quando é algo simples comprado ao que eu normalmente faço mas passou de uma sala é PostgreSQL

Penso que o motivo de tantos tutoriais usarem PostgreSQL e MySQL é porque são bancos de dados que frequentemente são usados em projetos reais de empresas. E para quem já trabalha e usa em projetos pessoas, imagino que seja por costume.

Eu sempre falo isso, mas pessoas não acreditam.

Se o SQLite performou igual ou é uma situação muito específica ou algo foi feito errado nele, porque é para ser bem melhor, na maioria dos casos.

Defendo muito o SQLite e cada vez mais com o surgimento de novas ferramentas e padrões de uso, mas tenho que dizer que não é para qualquer.

Essa coisa de "Migrar para outro banco de ados" é um mito, as pessoas carregam de penduricalhos achanado que um ia vai precisar, quase nunca vai acontecer, quando acontece é porque a pessoa é ruim demais, a migração não pode ser pura, não pode ser só usar a inicialização do ORM e boa, como muitos acham, dá muito mais trabalho, ao ponto que tentar abstrair faz a profecia ser auto realizável, você vai trocar porque tentou fazer algo genérico em vez de otimizar bem para um banco dados.

O banco de bem otimizado "opera milagres".

Eu tenho que admitir que o risco de ter que mudar para outra coisa depois quando se usa o SQLite, é maior que os outros candidatos tradicionais, mas ainda é pequeno se a pessoa não for completamente sem noção.

Tem sistemas enormes rodando com milhares de pessoas simultâneamos rodando SQLite. é Caro que a arquitetura e a necessidade especial é que permitaram isso. E podem crescer que fica tempo constante (essencialmente).

Tem casos que deve usar pg, my, Oracle, Sqlserver e outros, até firebird. SQLite serva pata muito mais que a maioria acha, mas não serve para tudo, especialmente se não for algo tão simples assim e a pessoa não sabe fazer nada certo. Tem que ser bom de arquitetura pro SQLite scalar, mas ele escala. A questão é achar o ponto onde o fazer funcionar bem pode sair mais caro que outra opção mais preparada para grandes escalas.

A esmagadora maioria das pessoas que trabalham com DB não está atualizada com tudo que ocorre na cena do SQLite, o que ele falarem é algo do passado que não vale mais hoje.

O SQLite tem algumas limitações em acerto ponto, mas escolha entre MySQL e PostgreSQL vai mais pelo gosto ou algo muito específico o que qualquer outras coisa. Ambos alguém firme os maiores sites do mercado, é só saber fazer.

SQL Server, Oracle e provavelmente DB (conheço quase nada) podem ser melhores em alguns casos, geralmente as versões mais varas, é como precisa do Core i9, quase ninguém precisa, mas se precisa desse pouquinho a mais ele entrega e arranca seus rins.

È bom lembrar que eu já escrevi artigos sobre DBs há 10 amos atrás que hoje tem valor quase zero, porque o mundo dá voltas. Então cuidado se estiver lento em 2035, 2030 ou 2027.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Eu usava sempre Postgres no back como default, comecei a usar SQLite como default faz uns 2 anos e não me arrependo!

Inclusive para apps iOS, parei com Core Data e agora vou direto no SQLitee não me vejo usando outra coisa para mobile.

O dia a dia é sempre tão corrido, que é verdade, as vezes a gente automatiza algumas decisões, porque nos trazem segurança, pode até não ser a melhor decisão para aquele projeto, mas a diferença não vai ser grande.

Na minha cabeça existem papéis determinados. Se vou fazer uma api, um serviço auxiliar, eu vou de mysql/mariadb. Tenho dois RDS e crio vários bancos ali dentro e separo as permissões para cada aplicação e boas, vida que segue.

Uma aplicação mais robusta, a mão coça pra usar mysql pela praticidade, mas acabo indo de Postgre.

Um ERP sempre vai ser MS Sql Server ou Oracle, mas isso só chega até nós, raramente estaremos na decisão de escolher um banco de dados de um ERP, e é uma delícia trabalhar com Sql Server.

Agora Sqlite, é só para banco de um app mobile, mas na outra ponta, na api certamente os dados virão de um outro banco mysql/postgre/firebase/dynamo. Porque apesar de toda evolução que possa ter acontecido, o conceito do sqlite e do firebird embedded é um arquivo de texto, que é acessado via drivers que padronizam e otimizam esse arquivo texto, mas não deixa de ser. A chance de um badblock, uma queda de energia, ou qualquer problema no servidor te fazer perder um banco de dados inteiro é com certeza muito maior do que nas outras opções onde você tem um serviço de banco de dados.

É aquela coisa, você testa e está funcionando, está lindo, mas quando a coisa cresce, os anos passam e acontece algum pepino você se arrepende por não ter escolhido algo mais robusto.