Why do projects that are meant to be lightweight use Postgres instead of SQLite? The latter is much easier to deploy (you, well, just don't need to), and does 99% of what anyone needs, and definitely 100% of what small projects need.
If what you need can suffice with SQLite, then Postgres will work too.
If you're running an app on a VM, running Postgres on it too is easy and isn't "big". It's easy to install and set up, and you're set up for all the features you may want later. Plus you avoid having to refactor for a different database later on.
If you're running your app in a serverless context, or on a PaaS/SaaS, etc, then SQLite might be easier. But maybe you want horizontal scalability with a shared dataset and then you're back at Postgres.
Just picking one thing "because everybody does" or "because it's lightweight" or "it works in most cases" etc aren't good reasons to pick technology. Look at your actual application, make a list of pros and cons, and choose based on your situation, not the cargo cult answer from the HN hive mind.
I use Postgres in my personal projects because I have a server (with backups etc.) running anyway. Since this project also has OIDC authentication, I imagine the target audience may already be running a PG server?
Cargo culting. If you never used SQLite, anytime you need a database you use whatever you've used before without shopping around or considering if what you're about to use is right.
Hang on a second- this project looks to be assuming that the db will be remote and over the internet. Even the SQLite official document recommends people to use PostresSQL in that scenario [0]:
>Generally, if your data is separated from the application by a network, you want to use a client/server database. This is due to the fact that the database engine acts as a bandwidth-reducing filter on the database traffic ... Use a client/server database engine. PostgreSQL is an excellent choice.
No, the project has two parts. One server and one client. The client obviously runs on a different host than the server, but nothing in the architecture says that the server and the db has to run on different hosts.
You can also see that the pgrokd.yml config example is connecting to the database via localhost, so running on the same machine as "pgrokd" (the server part of pgrok).
My mistake it looks as though the desiderata was single client/server db backend in the first place, and remote db was just an added bonus of that - https://github.com/pgrok/pgrok/pull/11
If you want a similar project which 'just works' then consider using zrok. Its fully opensource which you can self-host or use the free hosted version - https://zrok.io/
Yeah, in better news though, it seems to be using gorm which has different drivers available (https://gorm.io/docs/connecting_to_the_database.html), SQLite being one of them. So unless they are doing something postgres specific, should be relatively easy to switch it out.
