Abra o capô da maioria dos aplicativos de negócios e você descobrirá que eles têm alguma maneira de armazenar e usar dados estruturados. Seja um aplicativo do lado do cliente, um aplicativo com front-end da Web ou um aplicativo para dispositivos de ponta, é provável que um aplicativo de negócios precise de um banco de dados. Em muitos casos, um integrado banco de dados servirá. Os bancos de dados incorporados são leves, compactos e portáteis e, para alguns aplicativos, são uma escolha melhor do que um servidor tradicional.

SQLite é um banco de dados de código aberto incorporável, escrito em C e consultável com SQL convencional. O SQLite foi projetado para ser rápido, portátil e confiável, esteja você armazenando apenas kilobytes de dados ou blobs de vários gigabytes. Daremos uma olhada no SQLite, incluindo onde e quando usá-lo e como ele se compara a alternativas como MySQL, MariaDB e outros bancos de dados incorporados populares.

Para que é usado o SQLite?

O caso de uso mais comum e óbvio do SQLite é servir como um banco de dados relacional convencional orientado a tabelas. SQLite oferece suporte a transações e comportamentos atômicos, portanto, uma falha no programa ou mesmo uma queda de energia não deixará você com um banco de dados corrompido. SQLite também possui outros recursos encontrados em bancos de dados de ponta, como indexação de texto completo e suporte para bancos de dados grandes – até 281 terabytes com tamanhos de linha de até 1 GB.

SQLite também fornece uma maneira rápida e poderosa de armazenar dados de configuração de um programa. Em vez de analisar um formato de arquivo como JSON ou YAML, um desenvolvedor pode usar SQLite como uma interface para esses arquivos – geralmente muito mais rápido do que operar neles manualmente. SQLite pode trabalhar com dados na memória ou arquivos externos (por exemplo, arquivos CSV) como se fossem tabelas de banco de dados nativas, fornecendo uma maneira prática de consultar esses dados. Ele também oferece suporte nativo a dados JSON, para que os dados possam ser armazenados como JSON ou consultados no local.

Vantagens do SQLite

SQLite tem muitas vantagens, começando pela portabilidade de plataforma e linguagem. Aqui estão os principais benefícios de usar SQLite:

  • É multiplataforma: Uma das maiores vantagens do SQLite é que ele pode ser executado em praticamente qualquer lugar. SQLite foi portado para uma ampla variedade de plataformas: Windows, macOS, Linux, iOS, Android e muito mais. Os usuários do Windows, em particular, podem usar binários pré-compilados para Win32, UWP, WinRT e .Net normais. Qualquer que seja o destino de implantação do seu aplicativo, é provável que exista uma edição do SQLite disponível para ele ou uma maneira de portar o código-fonte C para esse destino.
  • É compatível com a maioria das linguagens de programação: Os aplicativos que usam SQLite não precisam ser escritos em nenhuma linguagem específica, desde que haja alguma maneira de vincular e trabalhar com bibliotecas externas escritas em C. Os binários do SQLite são independentes, portanto, não requerem nenhuma mágica específica para serem implantados —você pode simplesmente colocá-los no mesmo diretório do seu aplicativo.
  • Sim, SQLite funciona com Python: muitas linguagens possuem ligações de alto nível para SQLite como uma biblioteca e podem usá-las em conjunto com outras camadas de acesso ao banco de dados para a linguagem. Python, por exemplo, agrupa a biblioteca SQLite como um elemento padrão com a versão padrão do interpretador Python. Além disso, terceiros escreveram uma ampla variedade de ORMs e camadas de dados que usam SQLite, para que você não fique preso ao acessar o SQLite por meio de strings SQL brutas (o que não é apenas desajeitado, mas também potencialmente perigoso).
  • Autônomo: como o SQLite é um binário único e independente, é fácil implantá-lo com um aplicativo e, em seguida, migrar com o aplicativo conforme necessário. Cada banco de dados criado pelo SQLite também contém um único arquivo, que pode ser compactado ou otimizado por meio de comandos SQL.
  • Extensões de terceiros: Extensões binárias de terceiros para SQLite adicionam ainda mais funcionalidades. SQLCipher adiciona criptografia AES de 256 bits aos arquivos de banco de dados SQLite. Outro, sqlean, expande as funções nativas do SQLite para incluir muitas outras não disponíveis por padrão, como geração de UUIDs ou correspondência de expressões regulares.
  • Ferramentas extensas: muitos outros projetos de terceiros fornecem ferramentas adicionais para SQLite, como a extensão Visual Studio Code que permite navegar em bancos de dados no Visual Studio Code ou a linha de comando interativa LiteCLI para SQLite. Uma lista selecionada de recursos SQLite no GitHub inclui muito mais opções.
  • SQLite é código aberto: Por fim, o código-fonte do SQLite é de domínio público, portanto pode ser reutilizado em outros programas sem restrições práticas.

SQLite x MySQL

O SQLite é frequentemente comparado ao MySQL, o produto de banco de dados de código aberto amplamente utilizado e que é um elemento básico das pilhas de aplicativos atuais. Por mais que o SQLite se assemelhe ao MySQL, há bons motivos para preferir um ao outro, dependendo do caso de uso. O mesmo se aplica ao MariaDB, outro banco de dados popular que às vezes é comparado ao SQLite.

Tipos de dados

SQLite tem relativamente poucos tipos de dados nativos—BLOB, NULL, INTEGER, REALe TEXT. Tanto o MySQL quanto o MariaDB, por outro lado, possuem tipos de dados dedicados para datas e horas, várias precisões de números inteiros e flutuantes e muito mais.

Se você estiver armazenando relativamente poucos tipos de dados ou quiser usar sua camada de dados para realizar a validação dos dados, o SQLite é útil. No entanto, se você deseja que sua camada de dados forneça sua própria validação e normalização, escolha MySQL ou MariaDB.

Configuração e ajuste

As opções de configuração e ajuste do SQLite são mínimas. A maioria de seus sinalizadores internos ou de linha de comando lidam com casos extremos ou compatibilidade com versões anteriores. Isto se encaixa na filosofia geral de simplicidade do SQLite: as opções padrão são adequadas para os casos de uso mais comuns.

MySQL e MariaDB oferecem uma verdadeira floresta de opções de configuração específicas de banco de dados e instalação – agrupamentos, indexação, ajuste de desempenho, mecanismos de armazenamento, etc. A infinidade de opções ocorre porque esses produtos de banco de dados oferecem muito mais recursos. Talvez você precise ajustá-los mais, mas é provável que você esteja tentando fazer mais em primeiro lugar.

Banco de dados de usuário único vs. banco de dados multiusuário

SQLite é mais adequado para aplicações com um único usuário simultâneo, como em aplicativos desktop ou móveis. MySQL e MariaDB são projetados para lidar com vários usuários simultâneos. Eles também podem fornecer soluções em cluster e escaláveis, enquanto o SQLite não.

Alguns projetos adicionam recursos de escalonamento ao SQLite, embora não como um substituto direto do MySQL ou MariaDB. A Canonical criou sua própria variante do SQLite, dqlite, projetada para escalar horizontalmente em um cluster. Os dados são mantidos consistentes entre os nós por meio de um algoritmo Raft, e a implantação do dqlite tem apenas um pouco mais de sobrecarga administrativa do que o SQLite.

SQLite vs. bancos de dados incorporados

SQLite está longe de ser o único banco de dados incorporável. Muitos outros oferecem recursos semelhantes, mas enfatizam diferentes casos de uso ou modelos de implantação.

  • Apache Derby: um mecanismo SQL incorporável, também reembalado pela Oracle como Java DB. Como o Apache Derby é escrito em Java e requer JVM, ele foi projetado principalmente para incorporação em aplicativos Java.
  • Firebird incorporado: O banco de dados Firebird, que roda em plataforma cruzada e possui muitos recursos de ponta, está disponível como uma biblioteca que pode ser incorporada em uma aplicação cliente. Seu conjunto de recursos se compara bem ao SQLite, mas o SQLite tem uma comunidade de usuários e uma base de suporte muito maiores.
  • Reino: um banco de dados relacional de alto desempenho projetado para ambientes móveis (principalmente Android) que também é capaz de suportar ambientes de desktop como Windows. No entanto, o Realm é baseado em objetos e não usa consultas SQL – bom se você preferir não usar SQL, mas ruim se o SQL for familiar e confortável. Realm agora é um projeto MongoDB e vem com a ressalva de que “não é em si um produto de 'usuário final' com uma API publicamente estável e suportada”.
  • VistaDB: um banco de dados incorporado para o tempo de execução .Net. O VistaDB está disponível em versões específicas para os vários sabores e encarnações do .Net e com muitos recursos empresariais, como criptografia completa de banco de dados. No entanto, é um produto comercial, não de código aberto.
  • Banco de dados de Berkeley: um projeto Oracle, nominalmente um armazenamento de chave/valor, mas que usa SQLite em edições recentes como forma de lidar com consultas SQL. O mecanismo de banco de dados subjacente do Berkeley DB possui melhorias de desempenho que o SQLite não consegue igualar, como a capacidade de lidar com múltiplas operações de gravação simultâneas. Berkeley DB tem licença dupla, sob a GNU Affero GPL 3 ou por meio de uma licença comercial, dependendo do seu caso de uso.

Limitações do SQLite

As escolhas de design do SQLite o tornam adequado para alguns cenários, mas pouco adequado para outros. Aqui estão alguns lugares onde o SQLite não funciona bem:

  • Aplicativos que usam recursos que o SQLite não suporta: SQLite não oferece suporte – e em muitos casos não tentará oferecer suporte – vários recursos de banco de dados relacional. Muitos são casos esquivos, mas mesmo um deles pode quebrar o acordo.
  • Aplicativos que exigem designs escaláveis: as instâncias SQLite são singulares e independentes, sem sincronização nativa entre elas. Eles não podem ser federados ou transformados em um cluster. Qualquer aplicativo de software que use um design escalável não pode usar SQLite. Conforme observado acima, alguns terceiros estenderam o SQLite para adicionar esses recursos, mas eles não são nativos do design do SQLite.
  • Aplicativos com operações de gravação simultâneas de múltiplas conexões: o SQLite bloqueia o banco de dados para operações de gravação, portanto, qualquer coisa que envolva múltiplas operações de gravação simultâneas pode resultar em problemas de desempenho. No entanto, aplicativos com múltiplas leituras simultâneas geralmente são rápidos. SQLite 3.7.0 e superior fornecem o modo Write-Ahead Logging para fazer com que várias gravações funcionem mais rapidamente, mas vem com algumas limitações. Como alternativa, considere Berkeley DB, mencionado acima.
  • Aplicativos que precisam de digitação de dados forte: SQLite tem relativamente poucos tipos de dados – nenhum tipo nativo de data e hora, por exemplo. Isso significa que o aplicativo deve impor a maioria dos tipos. Se você deseja que o banco de dados, ao contrário do aplicativo, normalize e restrinja as entradas para valores de data e hora, o SQLite pode não funcionar para você.