Q:

Quando usar o SQLite?

Quando eu devo e não devo usar o SQLite?
Tenho um projeto que pretendo fazer não tenho ideia de quantas tabelas vão ser, mas acredito que mais de 15 com cerca de pelo menos mil linhas em algumas tabelas. 
Seria viável fazer no SQLite?

A:

Antes de começar usar um ferramenta você deve estudá-la profundamente. E depois de estudá-la terá informações para decidir por conta própria se ela é viável para seu caso ou não. Não confie em pessoas aleatórias na internet para dizer para você o que é bom ou não para você.
Se você estudar o SQLite certamente chegará nessa página. Ela diz onde o SQLite pode ser usado. Em resumo:

Dispositivos móveis e embarcados
Formato de arquivos
"Pequenos" websites
Análise de dados
Cache para dados corporativos
Banco de dados apenas no lado do servidor
Arquivamento de dados
Substituto para operações com arquivos comuns
Bancos temporários ou internos
Substituto para outros SGDBs em tarefas de teste e demonstração
Treinamento em banco de dados.

Lá diz onde não deve usar:

Aplicações cliente-servidor (tem como usar se souber fazer)
Websites de grande volume (lá fala em 1% dos sites, minha experiência mostra que é mais raro ainda)
Conjunto de dados absurdamente grandes (mas é raro quem tem esse volume todo)
Alta concorrência (o maior problema dele, mas poucos possuem essa necessidade)

Ou seja, o SQLite é adequado para quase todos os casos. E os casos onde ele não é adequado, a pessoa saberá, porque aí o problema é tão complexo que alguém inexperiente não estará envolvido. E se isto acontecer, a escolha errada do banco de dados será um problema pequeno perto dos outros que ela cometerá.
Claro que ele pode não te agradar, mas aí é outro problema. Eu uso o SQLite sempre que eu posso. Ele não é tão completo em recursos quanto outros bancos. Ele é ótimo para armazenamento e relacionamento básico. Em geral, os recursos dos outros banco de dados podem parecer ótimos no começo, mas é preciso aprender tudo e usar corretamente. Muitas vezes ter apenas o básico torna o trabalho mais simples sem perder funcionalidade importante. A maioria dos recursos existentes em produtos mais "potentes" são apenas facilitadores que podem ajudar ou atrapalhar. Eles não estão ali sem cobrar um preço.
O seu caso é extremamente simples e não deve ter problemas. Mas é preciso analisar como os dados serão acessados. Haverá grande concorrência? Duvido, então acho que não precisa se preocupar com isto. O acesso será por uma aplicação na mesma máquina? Isto é importante. O SQLite não se dá bem em acessos sendo feitos por outra máquina.
Ele não pode ser acessado confiavelmente de outras máquinas. Na prática á raro dar problema, mas pode acontecer. A solução é ter uma aplicação na máquina que o acesse e permita que outras máquinas se comuniquem com esta aplicação (veja o link acima). Por isto websites funcionam bem. O servidor HTTP e o código do website seguem justamente este modelo. Porque as pessoas não seguem o mesmo modelo para outros tipos de aplicação? Provavelmente porque seguem receitas de bolo e não pensam fora da caixa. Ou talvez porque não sabem como fazer.
Esta é a real decisão se deve usá-lo ou não. O volume de dados é secundário.
Então estude o produto para entender as limitações que ele possui em facilidades extras, em volume de concorrência (real), e acesso direto remoto. Sabendo disto saberá onde pode usar ou não. O site oficial é muito informativo.
Um exemplo de uso do SQLite em alta escala. Algumas pessoas não o usam, e acham que ele não escala, que não pode ser usado em quase todos os cenários no lugar de soluções mais completas. Ele só não é bom com muita concorrência de escrita e para ferramentas auxiliares ao banco de dados. Curiosamente essas pessoas costumam acreditar em NoSQL que costumam ser piores de leitura que o SQLite. As pessoas precisam pensar fora da caixa, investigar antes de fazer afirmações que atingem sua credibilidade.

A:

SQLite vc usa se tiver a necessidade de ter um cenário de dados em modo desconectado.
Exemplo:
Vc tem o seu sistema corporativo (15 tabelas com 1000 registros cada), mas precisa ir à campo (ambiente desconectado) usar uma aplicação com dados do seu sistema.
Então, vc cria uma base SQLite no dispositivo que vai a campo (mobile, laptop, etc) e traz para essa base apenas dados que irão atender a necessidade desta ida à campo. E, assim que esse dispositivo retornar à rede corporativa, vc cria uma logica de sincronismo para trazer os dados do SQLite de volta para a base de dados principal.

