Il limite realistico (della dimensione di alcuni database Sqlite) è lo stesso del limite realistico per un file di dati. E quel limite dipende molto dal tuo computer e amp; sistema. Sul mio attuale desktop Linux non posso permettermi molto più di un file 350Gbyte (perché come regola generale evito di avere un singolo file che mangia più di metà di una partizione del disco). A proposito, questo limite pratico influisce anche su altri RDBMS SQL come PostGreSQL o MariaDB (ma la maggior parte di questi tiene i dati in diversi file, che è possibile mantenere su diversi file system, e alcuni di essi sono in grado di gestirli dati distribuiti su macchine remote ...)
After reading this article I'm still not convinced to ever consider SQLite for anything that might require hundreds of gigabytes
Hai ragione e torto.
Hai ragione, perché sul computer di oggi (laptop e desktop, non supercomputer o server datacenter), un centinaio di gigabyte è ancora uno spazio su disco abbastanza grande. Quindi, in pratica, se si pensa a un database così grande, è meglio immaginare un vero server SQL (à la PostGreSQL), in particolare perché si potrebbe desiderare molto probabilmente un accesso remoto, un accesso effettivamente concorrente e probabilmente dati distribuiti e amp; tabelle.
Tu sei (in linea di principio, non ho mai provato) sbagliato perché molto probabilmente SQLite è in grado (e talvolta testato) di gestire un database di diverse centinaia di gigabyte, assumendo che tu abbia un filesystem in grado di gestire un file così grande (e probabilmente due di loro almeno).
Sicuramente (a volte) considero SQLite per database di diverse dozzine di gigabyte (e ho provato una volta un file .sqlite di grandi dimensioni, IIRC di 40Gbytes). Sulle attuali macchine (non supercomputer), esiterei con centinaia di gigabyte di database SQLite, semplicemente perché un tale file è abbastanza grande per la pratica odierna.
IIRC un fornitore di hardware che vendeva macchine per filesystem specializzati mi ha parlato di un'applicazione sqlite di un terabyte (ma potrei sbagliarmi).
Ovviamente le prestazioni SQLite dipendono (come tutti i database SQL) molto del numero e della larghezza delle tabelle, dei loro indici, delle query SQL coinvolte. E tu non vuoi avere accesso simultaneo (da molti processi diversi), e dovresti usare la transazione (per esperienza, anche su un piccolo database SQLITE di pochi megabyte, vuoi davvero racchiudere le tue es. Migliaia di richieste di inserimento con BEGIN TRANSACTION & END TRANSACTION , non farlo sta rallentando Sqlite di un grande fattore -più di 10x -).
E per esperienza personale, con configurazione e organizzazione adeguate, SQLite è in grado di gestire un database più grande della RAM disponibile (quindi 30Gbyte non è un problema) - ma probabilmente vorrai che gli indici si adattino alla RAM!
Se ti capita di codificare qualcosa per un "supercomputer" o una costosa workstation (con ad esempio 512 GB di RAM e 8 TB di disco e 512 GB di SSD), puoi sicuramente disporre di un database Sqlite di terabyte. Ma vorrai farlo forse solo se uno (o pochissimi) processi sta accedendo a quel database. Se hai una dozzina di processi che accedono contemporaneamente allo stesso database, installa meglio un vero RDBMS SQL (alla MariaDB o PostGreSQL)
Si noti inoltre che mentre il formato (binario) dei file di database .sqlite è documentato come "portatile", ho molto preferire il backup dei database nel formato SQL testuale (utilizzando sqlite3 mydb.sqlite .dump > mydb.sql ). Quindi, ho anche bisogno di spazio aggiuntivo su disco per quel dump testuale (e questo riduce il limite realistico).
Solitamente Sqlite non è il collo di bottiglia. Ma il disco potrebbe essere.
PS. Lo stesso ragionamento potrebbe essere applicato a file indicizzati di grandi dimensioni utilizzando GDBM .
PPS. Nella mia expjs filiale (sept.2016) del mio monitor MELT (software gratuito GPLv3, su github ) Sono persistente l'intero heap dell'applicazione in JSON all'interno di un nuovo database Sqlite. Ho eseguito piccoli esperimenti con diversi milioni di oggetti (abbastanza "grandi") senza brutte sorprese. YMMV.