s/postgres/sqlite/g

hshdhdhehd 2 days ago | parent | next [-]

Postgres is simpler. Get your cloud to manage it. Click to create instance, get failover with zero setup. Click button 2 to get guaranteed backups and snapshot point in time.

▲

1718627440 2 days ago | parent [-]

When you use sqlite, you can distribute your program by distributing a single executable file. That's what I call simple.

▲

hshdhdhehd a day ago | parent [-]

Yes that is simple, especially for a desktop app.

I would argue it is not resilient enough for a web app.

No one wrote the rules in stone, but I assume server side you want the host to manage data recovery and availability. Client side it is the laptop owners problem. On a laptop, availability is almost entirely correlated with "has power source" and "works" and data recovery "made a backup somehow".

So I think we are both right?

	▲	1718627440 a day ago \| parent [-]
		I was especially thinking about a program running on a server. I wouldn't statically link everything for a desktop program, because it just causes incompatibilities left-and-right. But for a server, you don't have external vendors, so this is a good option, and if you use SQLite as the database, then this means that deploying is not more complicated than uploading a single executable and this is also something, that can be done atomically. I don't see how this has worse effects on recovery and availability. The data is still in a separate file, that you can backup and the modification still happens through a database layer which handles atomic transactions and file system interaction. The availability is also not worse, unless you would have hot code reloading without SQLite, which seems like an orthogonal issue.

▲

Komte 2 days ago | parent | prev | next [-]

Don't agree. Getting managed postgress from one of the myriad providers is not much harder than using sqlite, but postgress is more flexible and future proof.

	▲	eskibars 2 days ago \| parent \| next [-]
		Isn't the entire point of this post that many companies opt for flexible+future proof far too prematurely?
	▲	ErroneousBosh 2 days ago \| parent \| prev [-]
		I use Postgres for pretty much everything once I get beyond "text in a database with a foreign key to a couple of things". Why? Because in 1999 when I started using PHP3 to write websites, I couldn't get MySQL to work properly and Postgres was harder but had better documentation. It's ridiculous spinning up something as "industrial strength" as Postgres for a daft wee blog, just as ridiculous as using a 500bhp Scania V8 for your lawnmower. Now if you'll excuse me, I have to go and spend ten seconds cutting my lawn.

▲

StarGrit 2 days ago | parent | prev | next [-]

ORMs have better support I've found in the past (at least in .NET and Go) for Postgres. Especially around date types, UUIDs and JSON fields IIRC.

▲

Hendrikto 2 days ago | parent [-]

You don’t need an ORM either. It’s just another level of complexity for very little to no gain in almost all cases. Just write SQL.

	▲	StarGrit 2 days ago \| parent [-]
		You always get a comment like this. I don't particularly agree. There are pros and cons to either approach The tooling in a lot of languages and frameworks expects you to use an ORM, so a lot of the time you will have to put up a fair bit of upfront effort to just use Raw SQL (especially in .NET land). On top of that ORM makes a lot of things that are super tedious like mapping to models extremely easy. The performance gains of writing SQL is very minor if the ORM is good.

▲

rcarmo 2 days ago | parent | prev | next [-]

This. So much this. Of course, at one point you start wanting to do queues, and concurrent jobs, and not even WAL mode and a single writer approach can cut it, but if you've reached that point then usually you a) are in that "this is a good problem to have" scalability curve, and b) you can just switch to Postgres.

I've built pretty scalable things using nothing but Python, Celery and Postgres (that usually started as asyncio queues and sqlite).

	▲	forgetfulness 2 days ago \| parent [-]
		A queue and a database are more shots on the architecture golf though.

▲

anonzzzies 2 days ago | parent | prev | next [-]

Yeah, we run a fairly busy systems on sqlite + litestream. It's not a big deal if they ae down for a bit (never happened though) so they don't need failover and we never had issues (after some sqlite pragma and BUSY code tweaking). Vastly simpler than running + maintaining postgres/mysql. Of course, everything has it's place and we run those too, but just saying that not many people/companies need them really. (Also considering that we see system which DO have postgres/mysql/oracle/mssql set up in HA and still go down for hours do a day per year anyway so what's it all good for).

▲

sachahjkl 2 days ago | parent | prev [-]

back in the day, the hype was all arround postgres, but I agree