1. Why look beyond SQLite at all
Lesson 13 covered when SQLite is enough: single-writer workloads, embedded apps, prototypes, low-traffic sites, edge deployments where a file-based database is genuinely simpler than running a server. The moment any of these stop being true — multiple app servers writing at once, traffic that needs to scale horizontally, a team that wants managed backups/replicas without babysitting a file — you need a database that runs as its own server process (or managed service) instead of living inside your application process.
That's the common thread across everything in this lesson: Postgres, MySQL, Turso, and PlanetScale all decouple the database from the application, so multiple clients can connect, write concurrently, and be managed independently of any single app deploy.
2. PostgreSQL
What it is: an open-source, general-purpose relational database, in continuous development since the late 1980s. Often just called "Postgres". It's the closest thing the industry has to a default choice for a serious relational database today.
Why it exists / why people reach for it: it combines strict SQL standard compliance with a huge set of advanced features most competitors lack out of the box — JSON/JSONB columns (documents inside a relational table), full-text search, geographic data types (PostGIS), array columns, custom types, and a mature extension ecosystem (like pgvector for embeddings).
Pros
- Extremely feature-rich: JSON, arrays, full-text search, extensions — often removes the need for a separate specialized database.
- Strong correctness guarantees (ACID transactions, strict data typing) — fewer silent data corruption surprises than MySQL historically had.
- Free, open-source, no vendor lock-in for the engine itself; available from every major cloud and countless managed providers (Neon, Supabase, RDS, Vercel Postgres, etc.).
- Huge community, extension ecosystem, and tooling maturity.
Cons
- Vertical scaling has limits — very large write-heavy workloads eventually need sharding or read replicas, which add operational complexity.
- Configuration for performance (connection pooling, vacuuming, indexes) has a real learning curve compared to "it just works" file databases.
- Running it yourself means managing backups, updates, and failover — most teams offload this to a managed provider instead.
3. MySQL
What it is: another open-source relational database, historically the default pick for web applications (the "M" in the old LAMP stack — Linux, Apache, MySQL, PHP). Owned by Oracle since 2010, though a fully open fork (MariaDB) exists for teams wary of that.
Why it exists / why people reach for it: it prioritizes simplicity and raw read speed for straightforward web workloads. It's what WordPress, most PHP frameworks, and a huge share of legacy web applications run on — meaning enormous hosting support and familiarity.
Pros
- Extremely well understood, huge hosting support (practically every shared host offers it), enormous body of existing tutorials and tooling.
- Historically faster for simple read-heavy workloads than Postgres, though this gap has narrowed significantly over the years.
- Simpler mental model — fewer advanced features means less to configure wrong.
Cons
- Fewer advanced data types and features than Postgres (weaker JSON support, no native arrays, fewer extension options).
- Historically looser data-type enforcement (silently truncating or coercing invalid values) — improved in recent versions but still a real gotcha for teams migrating from Postgres.
- Owned by Oracle, which makes some teams (and some open-source purists) prefer MariaDB or Postgres instead.
4. Turso
What it is: a managed, distributed database built on libSQL — an open-source fork of SQLite designed to run as a server, not just as an embedded file. Think of it as "SQLite's file-based simplicity, but as a real client-server database you can deploy at the edge."
Why it exists / why people reach for it: it targets a very specific gap — teams who love SQLite's simplicity and low cost, but need it reachable over the network from serverless/edge functions (Vercel, Cloudflare Workers) where a local file isn't an option. It also supports "embedded replicas": a local SQLite file that syncs from a central Turso database, giving near-zero read latency plus a durable source of truth.
Pros
- Keeps SQLite's simplicity and low operational overhead while adding real multi-writer, networked access.
- Edge-friendly: databases can be replicated close to users for very low read latency, which fits serverless/edge deploys (see Lesson 8's ISR discussion and Lesson 9/10 on Vercel/Netlify edge functions).
- Generous free tier, low cost for small-to-medium apps.
Cons
- Younger ecosystem than Postgres/MySQL — fewer battle-tested integrations, smaller community, less institutional knowledge to lean on when something breaks.
- Inherits some of SQLite's underlying constraints for very heavy concurrent-write workloads, even though libSQL improves on them.
- Vendor-specific product (not just "open-source Postgres you can self-host anywhere") — some lock-in to Turso's platform for the managed/distributed features.
5. PlanetScale
What it is: a managed database platform built on MySQL-compatible storage (originally Vitess, the sharding layer YouTube built for MySQL at scale; PlanetScale later also introduced a Postgres-based offering). Known especially for schema branching — treating database schema changes like Git branches.
Why it exists / why people reach for it: it solves the operational pain of scaling MySQL horizontally (which normally requires deep Vitess expertise to run yourself) and the workflow pain of making schema changes safely in a team — branch a schema change, test it, merge it, with automatic non-blocking migrations instead of risky manual ALTER TABLE statements on a live table.
Pros
- Schema branching + non-blocking schema changes are a genuinely different workflow than most databases offer — safer team collaboration on schema evolution.
- Built on Vitess, so horizontal scaling (sharding) is handled for you instead of being a manual, expert-only operation.
- Fully managed: no server patching, backups handled, generous free tier for small projects.
Cons
- No foreign key constraints in the MySQL/Vitess-based product by default (a consequence of the underlying sharding architecture) — some teams find this a meaningful trade-off versus Postgres.
- Managed-only — there's no realistic "self-host PlanetScale yourself" path the way there is with Postgres or MySQL.
- Pricing and feature set are tied to a single vendor's roadmap.
6. Side-by-side comparison
| Database | Core model | Best fit | Watch out for |
|---|
| Postgres | Open-source relational, self-host or managed anywhere | Default choice for most new apps; anything needing advanced data types or extensions | Performance tuning has a learning curve |
| MySQL | Open-source relational, huge legacy footprint | Simple web apps, existing MySQL-based stacks (WordPress, legacy PHP) | Weaker advanced features, historically looser type enforcement |
| Turso | Distributed SQLite (libSQL), managed | Edge/serverless apps wanting SQLite-like simplicity with real network access | Younger ecosystem, vendor-specific platform |
| PlanetScale | Managed, Vitess-sharded MySQL (also offers Postgres) | Teams needing horizontal scale and safe team schema workflows without deep DB-ops expertise | No FK constraints by default on the MySQL product; fully managed only |
7. How to actually choose, in practice
Default answer for a new project: Postgres, hosted on a managed provider (Neon, Supabase, Vercel Postgres, RDS). It's the safest "won't regret this in two years" choice — richest feature set, biggest community, least vendor lock-in.
Building on the edge/serverless with SQLite-style simplicity in mind: Turso — you keep the low-friction mental model from Lesson 13 while getting a real networked, multi-writer database.
Already on MySQL, or expecting to need serious horizontal scale with frequent schema changes across a team: PlanetScale — it turns two of MySQL's classic operational headaches (sharding, risky migrations) into a managed, workflow-friendly experience.
Practical example: imagine a small SaaS starting as a side project. It launches on SQLite (Lesson 13) because it's one founder, low traffic, and zero ops overhead. Six months in, a second background worker needs to write to the same database concurrently, and traffic has grown past what a single file handles comfortably. At that point, migrating to a managed Postgres instance is usually the least risky move — same relational model, same SQL dialect family, just now running as a proper server that multiple processes can talk to at once.
1. Por que olhar além do SQLite
A Lição 13 cobriu quando o SQLite basta: cargas de trabalho com um único escritor, apps embarcados, protótipos, sites de baixo tráfego, deploys de edge onde um banco baseado em arquivo é genuinamente mais simples que rodar um servidor. No momento em que qualquer uma dessas premissas deixa de valer — múltiplos servidores da aplicação escrevendo ao mesmo tempo, tráfego que precisa escalar horizontalmente, um time que quer backups/réplicas gerenciados sem cuidar de um arquivo na mão — você precisa de um banco que rode como processo de servidor próprio (ou serviço gerenciado), em vez de viver dentro do processo da aplicação.
Esse é o fio condutor de tudo nesta lição: Postgres, MySQL, Turso e PlanetScale desacoplam o banco da aplicação, permitindo que múltiplos clientes se conectem, escrevam de forma concorrente, e sejam gerenciados independentemente de qualquer deploy específico da aplicação.
2. PostgreSQL
O que é: um banco relacional de propósito geral, open-source, em desenvolvimento contínuo desde o fim dos anos 1980. Frequentemente só chamado de "Postgres". É o que mais se aproxima de uma escolha padrão da indústria pra um banco relacional sério hoje.
Por que existe / por que as pessoas usam: ele combina conformidade estrita com o padrão SQL com um conjunto enorme de recursos avançados que a maioria dos concorrentes não tem de fábrica — colunas JSON/JSONB (documentos dentro de uma tabela relacional), busca full-text, tipos de dados geográficos (PostGIS), colunas de array, tipos customizados, e um ecossistema maduro de extensões (como o pgvector pra embeddings).
Prós
- Extremamente rico em recursos: JSON, arrays, busca full-text, extensões — muitas vezes remove a necessidade de um banco especializado separado.
- Garantias fortes de correção (transações ACID, tipagem estrita de dados) — menos surpresas silenciosas de corrupção de dados do que o MySQL historicamente teve.
- Gratuito, open-source, sem vendor lock-in pro motor em si; disponível em toda grande cloud e inúmeros provedores gerenciados (Neon, Supabase, RDS, Vercel Postgres, etc).
- Comunidade enorme, ecossistema de extensões e maturidade de ferramental.
Contras
- Escala vertical tem limites — cargas muito pesadas de escrita eventualmente precisam de sharding ou réplicas de leitura, o que adiciona complexidade operacional.
- Configuração pra performance (connection pooling, vacuum, índices) tem uma curva de aprendizado real comparado a bancos baseados em arquivo que "simplesmente funcionam".
- Rodar você mesmo significa gerenciar backups, atualizações e failover — a maioria dos times terceiriza isso pra um provedor gerenciado.
3. MySQL
O que é: outro banco relacional open-source, historicamente a escolha padrão pra aplicações web (o "M" do antigo stack LAMP — Linux, Apache, MySQL, PHP). Propriedade da Oracle desde 2010, embora exista um fork totalmente aberto (MariaDB) pra times receosos disso.
Por que existe / por que as pessoas usam: ele prioriza simplicidade e velocidade bruta de leitura pra cargas web diretas. É o que roda o WordPress, a maioria dos frameworks PHP, e uma fatia enorme de aplicações web legadas — significando suporte de hospedagem e familiaridade enormes.
Prós
- Extremamente bem compreendido, suporte de hospedagem enorme (praticamente todo host compartilhado oferece), corpo enorme de tutoriais e ferramental já existentes.
- Historicamente mais rápido em cargas simples de leitura que o Postgres, embora essa diferença tenha diminuído bastante ao longo dos anos.
- Modelo mental mais simples — menos recursos avançados significa menos coisa pra configurar errado.
Contras
- Menos tipos de dados e recursos avançados que o Postgres (suporte a JSON mais fraco, sem arrays nativos, menos opções de extensão).
- Historicamente aplicação mais frouxa de tipos (truncando ou convertendo valores inválidos silenciosamente) — melhorou em versões recentes mas ainda é uma pegadinha real pra times migrando do Postgres.
- Propriedade da Oracle, o que faz alguns times (e alguns puristas de open-source) preferirem MariaDB ou Postgres.
4. Turso
O que é: um banco distribuído e gerenciado construído sobre o libSQL — um fork open-source do SQLite desenhado pra rodar como servidor, não só como arquivo embarcado. Pense nele como "a simplicidade baseada em arquivo do SQLite, mas como um banco cliente-servidor de verdade que dá pra publicar na borda (edge)."
Por que existe / por que as pessoas usam: ele mira numa lacuna bem específica — times que amam a simplicidade e o baixo custo do SQLite, mas precisam acessá-lo pela rede a partir de funções serverless/edge (Vercel, Cloudflare Workers) onde um arquivo local não é uma opção. Também suporta "réplicas embarcadas": um arquivo SQLite local que sincroniza a partir de um banco Turso central, dando latência de leitura quase zero mais uma fonte de verdade durável.
Prós
- Mantém a simplicidade do SQLite e a baixa carga operacional enquanto adiciona acesso real de múltiplos escritores pela rede.
- Amigável pra edge: bancos podem ser replicados perto dos usuários pra latência de leitura muito baixa, o que combina com deploys serverless/edge (veja a discussão de ISR da Lição 8 e as edge functions de Vercel/Netlify das Lições 9/10).
- Camada gratuita generosa, custo baixo pra apps pequenas e médias.
Contras
- Ecossistema mais jovem que Postgres/MySQL — menos integrações testadas em batalha, comunidade menor, menos conhecimento institucional pra recorrer quando algo quebra.
- Herda algumas das restrições subjacentes do SQLite pra cargas muito pesadas de escrita concorrente, mesmo que o libSQL melhore nisso.
- Produto específico de fornecedor (não é só "Postgres open-source que você pode auto-hospedar em qualquer lugar") — algum lock-in na plataforma da Turso pros recursos gerenciados/distribuídos.
5. PlanetScale
O que é: uma plataforma de banco gerenciada construída sobre armazenamento compatível com MySQL (originalmente o Vitess, a camada de sharding que o YouTube construiu pro MySQL em escala; a PlanetScale depois também lançou uma oferta baseada em Postgres). Conhecida especialmente pelo branching de schema — tratar mudanças de esquema de banco como branches do Git.
Por que existe / por que as pessoas usam: ele resolve a dor operacional de escalar o MySQL horizontalmente (que normalmente exige expertise profunda em Vitess pra rodar você mesmo) e a dor de workflow de fazer mudanças de schema com segurança num time — branch de uma mudança de schema, testa, faz merge, com migrações automáticas e não-bloqueantes em vez de comandos ALTER TABLE arriscados e manuais numa tabela em produção.
Prós
- Branching de schema + mudanças de schema não-bloqueantes são um workflow genuinamente diferente do que a maioria dos bancos oferece — colaboração mais segura em time na evolução do schema.
- Construído sobre o Vitess, então escala horizontal (sharding) é resolvida pra você em vez de ser uma operação manual só pra especialistas.
- Totalmente gerenciado: sem patch de servidor, backups resolvidos, camada gratuita generosa pra projetos pequenos.
Contras
- Sem constraints de foreign key no produto baseado em MySQL/Vitess por padrão (consequência da arquitetura de sharding subjacente) — alguns times acham isso um trade-off significativo frente ao Postgres.
- Só gerenciado — não existe um caminho realista de "auto-hospedar a PlanetScale você mesmo" como existe com Postgres ou MySQL.
- Preço e conjunto de recursos atrelados ao roadmap de um único fornecedor.
6. Comparação lado a lado
| Banco | Modelo central | Melhor encaixe | Atenção a |
|---|
| Postgres | Relacional open-source, auto-hospedado ou gerenciado em qualquer lugar | Escolha padrão pra maioria dos apps novos; qualquer coisa que precise de tipos de dados ou extensões avançadas | Ajuste fino de performance tem curva de aprendizado |
| MySQL | Relacional open-source, pegada legada enorme | Apps web simples, stacks já baseados em MySQL (WordPress, PHP legado) | Recursos avançados mais fracos, aplicação de tipos historicamente mais frouxa |
| Turso | SQLite distribuído (libSQL), gerenciado | Apps edge/serverless que querem simplicidade estilo SQLite com acesso real pela rede | Ecossistema mais jovem, plataforma específica de fornecedor |
| PlanetScale | MySQL gerenciado e fragmentado via Vitess (também oferece Postgres) | Times que precisam de escala horizontal e workflows seguros de schema em time sem expertise profunda em DB-ops | Sem constraints de FK por padrão no produto MySQL; só gerenciado |
7. Como escolher, na prática
Resposta padrão pra um projeto novo: Postgres, hospedado num provedor gerenciado (Neon, Supabase, Vercel Postgres, RDS). É a escolha mais segura de "não vou me arrepender disso daqui a dois anos" — conjunto de recursos mais rico, maior comunidade, menos lock-in de fornecedor.
Construindo na edge/serverless com a simplicidade estilo SQLite em mente: Turso — você mantém o modelo mental de baixo atrito da Lição 13 mas ganha um banco real de rede, com múltiplos escritores.
Já está no MySQL, ou espera precisar de escala horizontal séria com mudanças frequentes de schema num time: PlanetScale — ele transforma duas das dores operacionais clássicas do MySQL (sharding, migrações arriscadas) numa experiência gerenciada e amigável ao workflow.
Exemplo prático: imagine um SaaS pequeno começando como projeto paralelo. Ele lança com SQLite (Lição 13) porque é um fundador só, tráfego baixo, e zero carga operacional. Seis meses depois, um segundo worker em background precisa escrever no mesmo banco de forma concorrente, e o tráfego cresceu além do que um único arquivo aguenta confortavelmente. Nesse ponto, migrar pra uma instância Postgres gerenciada costuma ser o movimento de menor risco — mesmo modelo relacional, mesma família de dialeto SQL, só que agora rodando como um servidor de verdade com o qual múltiplos processos podem falar ao mesmo tempo.