Comment by olivia-banks

> in many cases, sometimes you just want (relative) simplicity, both in terms of complexity and deployment, and should use something like SQLite.

So many times when trying to just go for simplicity with SQLite it takes me like one working day until I run up against enough annoyances to where resolving those is more work than setting up the "set up and forget" postgres instance.

Granted, this is for personal stuff... but "Postgres packaged for low maintenance" is present in a lot of OS package managers! Even for smaller data analysis work SQLite perf leads _loads_ to be desired (once had QGIS struggling with a sqlite DB... pg made everything mostly instant. Indices etc... but stuff I _couldn't easily get with sqlite_)

If SQLite works for you that's great, I do think it's worth it for people to _try_ to do simple pg setups to understand just how painful it is to use pg (for me: not that high)

I am also a fan of SQLite. One of the best parts during development is how easy it is to spin up and spin down databases for full integration tests without containers or anything. It also simplifies backups, and is probably good enough.

Where I have used SQLite most successfully is really two use cases. First, I use it for data processing. Say I need to retrieve lots of data and transform it to a different setup. I could do that in something like Python but SQL is just more expressive for that and I can also create a new database, populate it with data I have, fetch new data, combine it together, export the update to a permanent data store (usually Postgres).

Second, when I need a local save file. Sometimes small local apps are better served by a save file and they save file might as well have an extensible format that I can update as I go. This is more rare but still can be useful.

The first use case is very powerful. A temporary SQL database that can be blown away with zero trace of it is great. And the ability to run complex queries on it can really help.

But 99% of the time I just use Postgres. It works, it has sane defaults, it is crazy extensible, and it has never not met my needs, unlike Oracle or MySQL.

i think the topic of "what data backend" gets super conflated into many different variations of what the hell people need it for. discussions here go so many different directions. some people are building simple webapps, some are building complex webapps that need to scale for a gazillion users, some are building local apps, some are just tinkering, some are thinking broadly about how their backend needs to sync with a datalake->some data warehouse at an org, yadda yadda ya.

i personally like postgres myself for just about all use cases that must be shared with others (app with more than one client that might be providing CRUD updates or anything really that demands a central data store). ive used sqlite a couple times with WAL to try and make a small app shared between 2-3 people who all would contribute updates thru it but it wasnt ideal. for postgres so many features/extensions its concurrent writes are fast as hell and if you just want to one-shot a solution then you cant go wrong, but it's ofc not the same as sqlite setup.

i think a lot of the pain with postgres is just learning to effectively be a knowledgeable db admin of sorts. its somewhere between being a competent devops guy and a dbadmin expert all in one. if you're actually doing some kind of production deployment it is kinda scary hoping you've got everything set up right. even supabase which makes this whole process trivial to get going requires an understanding of not-always-understood security premises that just make things spooky.

lot of words to say i dont get much out of these discussions tbh. theres just too many use cases and variables in everyones working/hobby lives im not sure that there is a proverbial bottom to any of it. some will use sqlite and some will use postgres and some will use some weird thing no ones heard of because they're afraid to rawdog sql and just want immediate graphql capability to be the main mode of data retrieval. some will show up here and talk about why you need redis in the middle.

its too much noise so i just keep using postgres because its free and boring and fast. end of the day i just want to make stuff people can use. it's a hard endeavor to do well alone, if you dont have a team of other experts who can help you put all the puzzle pieces together on how to deploy things the right way and also add pieces like redis or whatever... it's just a lot. it's hard to find where to get started. sqlite is the only solution that really by nature of what it is seems to champion the lonely developer, but the tradeoffs are big if you're trying to make something that should get used by many people.

A bit off topic but the one thing I've never been able to figure out with Postgres easily & reliably is what magic incantations allow a user account full access to a specific database but not to others, particularly in cases of managed postgres offered by cloud providers. `GRANT ALL PRIVILEGES` never seems to work.

Having to look up and spend time fixing permissions every time itself makes using Postgres for simple uses difficult for me but if you're using it ad hoc, any tips?

I wish PostgreSQL had a native vector implementation instead of using extensions. They're kind of a pain in the ass to maintain, especially with migrations.

Because it's not web scale, mongoDB is web scale

See also, PGLite: https://pglite.dev/

And Turso: https://turso.tech/

Standardizing on one single tiny little project is always a bad idea. Why? Some examples (which are admittedly not related to postgres, because I don't know their structure):

1) A single person, doing a ton of heavy lifting, leaves, or worse, turns it over, or silently sells out to a nefarious person.

2) A severe security vulnerability is found. If everyone is using postgres, everyone is vulnerable. Bonus points if the vulnerability is either not publicly disclosed or it is hard to fix.

3) Commercial/Government interests heavily influence and push the project into places that could make it vulnerable in any given way. This is absolutely a thing.

4) AI. No clarification here. Just use your imagination, with recent news regarding FFMPEG and other projects in mind.