People talk about SQLite and PostgreSQL in the same breath because both are SQL databases. That is where the similarity ends. One is a library you embed in your application; the other is a server you run. The task is not picking the "better" one, it is picking the right one for where your data lives.
What they are
SQLite is an embedded, serverless database. Created by D. Richard Hipp with an initial release in August 2000, it is a C library that stores the whole database in a single file on disk, with no separate process to connect to. It is public domain software and is widely considered the most widely deployed database engine in the world, shipped inside smartphones, browsers, and desktop apps.
PostgreSQL descends from the Postgres research project that started at the University of California, Berkeley, in 1986 under Michael Stonebraker, and was renamed PostgreSQL in 1996 to reflect SQL support. It is a client-server relational database: a server process manages the data, and applications connect to it over the network or a socket. It is one of the most feature-complete open source databases, with a permissive PostgreSQL License.
The short version: SQLite is inside your process and is the database file itself. PostgreSQL is a service you connect to.
Where each shines
SQLite wins on simplicity and operational cost. Nothing to install as a server, no daemon to keep running, no configuration, no connection strings, no credentials. The result is a single portable file you can copy, back up, or commit to testing. For local tooling, scripts, embedded storage, and any workload on a single machine or a single writer, it is often all you need. It also works fine in production within its limits, and it has first-class support for transactions and concurrent reads.
PostgreSQL wins when you grow beyond one process. It handles many concurrent writers, which SQLite deliberately does not: SQLite allows only one writer at a time because of how it locks the database file. PostgreSQL gives you a real server with networking, per-user authentication, roles, and fine-grained access control. It is built for many clients, high write concurrency, and data that lives on a machine separate from the application.
How to choose
A decent rule of thumb. Need a database embedded inside an app, a small tool, or a phone? SQLite. Building a web service with multiple users, app instances, or a need for concurrent writes, or where the database will outlive a single process? PostgreSQL.
The middle of the spectrum is where people get stuck, and the honest answer is that you can start with SQLite and move later. Both are SQL, so most schema and queries port over with modest effort. Plenty of teams prototype in SQLite and migration to PostgreSQL when they need the server features, and tools exist to move the data. You are not locked in the way you are with some proprietary stacks.
One more honest difference worth the price of admission: PostgreSQL, because it is a real database server, brings real administration with it, backups, upgrades, tuning, and a service to keep alive. SQLite asks almost none of that of you. If you are not ready to run a database service, a file is a very reasonable place to start.