Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.
If you mean database size, SQLite can handle massive amounts of data. I've seen 281 TB quoted as theoretical max size.
From multi-client architecture and with regional HA?
SQLite is embedded for local applications with one writer mostly.
Postgres is for a client-server architecture with many writers.
When you start a project, you generally know which architecture you need.
though they also have "pglite" running in wasm.
same concept though, sync slices to an embedded db.
In 2026 that advice feels antiquated. SQLite now is absolutely useful now for concurrent, mutli-writer applications.
[1] - https://andersmurphy.com/2025/12/02/100000-tps-over-a-billio...
I don’t even think SQLite lets you fully update a table schema.
If you start trying to use it for sql and not just storing rows you run into these everywhere. SQLite is not serving the same needs as Postgres.
CREATE TRIGGER update_customer_emails_trigger INSTEAD OF UPDATE ON customer_emails BEGIN UPDATE customers SET email = new.email, name = new.name WHERE id = old.id; END;
Maybe that's not as flexible as you need.
SQLites process for table updates can be pretty onerous if their ALTER TABLE lacks support. Its a 12 step process the docs have the temerity to call "simple" instead of "tedious and risky" - https://www.sqlite.org/lang_altertable.html#otheralter
As their saying goes, it competes with fopen not oracle.
My example for android app:
https://f-droid.org/pl/packages/io.github.rumcajs.offlineweb...
Note that I am not android experienced programmer, and I am still learning.
use what you're familiar with, until it stops working. then use something else. postgres just goes a lot further than a lot of other tools before you get to the "use something else" phase. and postgres is the database a lot of people are familiar with.
In my previous company we used MongoDB, for almost everything, including text logs, request logs, job-queues and small template files. We added S3 since storing terabytes of files in a database is expensive. Now, I wouldn't choose MongoDB for a new app, since the data model and query language suck, but it performed reasonably across many use-cases.
For my next application I will use Postgres as primary database. Probably will integrate S3 before going live, to avoid the necessary data migration later, but haven't decided yet if that's a premature optimization.