Live data from Hacker News

Just use Postgres

mccue.dev

181–190 of 238 posts

Re: Just use Postgres

#181

Earlier quoted context omitted.

> "Push all your business logic into big long stored procedures/functions - don't be pulling the data back and munging it in some other language - make the database do the work!" This is one of the categories of opinions that I’ve heard, the proponents of which suggest that databases will typically be more efficient at querying and transforming data, since you’ll only need to transfer the end result over a network an…

Thank you :)

Ofc I reserve the right to be wrong, just wanted to share my subjective experience, that there can be tradeoffs and there probably aren't any silver bullets.

For the most part, I think that you should put any mass/batch processing in the DB (just comment/version/test/deploy your code like you would on the back end, as best as you can with the tools available to you) and don't sweat too much about handling the CRUD operations in your back end, through whatever ORM you use or don't use (regular queries are also fine, as long as parametrized to prevent injection).

For complex schemas, a nice approach I've found is making one DB view per table/list/section of your front end, so you only need 1 DB call to load a particular component, otherwise the N+1 risk gets far greater ("Oh hey, I got this list of orders, but each other needs a delivery status, so I'll just iterate over those and fetch them for each item, whoops, the DB is spammed with requests.").

Good luck!

Re: Just use Postgres

#182

Earlier quoted context omitted.

You don't need to maintain, secure and tweak postgres any more than you would with SQLite. Just install it and it'll work. Postgres backup is a single command. And actually you're supposed to create sqlite backups with special command as well, if you're copying a file, you're doing it wrong. I really don't see any cons with Postgres over SQLite for server applications.

> You don't need to maintain, secure and tweak postgres any more than you would with SQLite. That's not true. Postgres is another standalone process, SQLite is a library. Even if you have your service and Postgres on the same box, you need to account for yet another process that can independently go down, that is competing for resources etc...

I've never had Postgres "go down". It might if you run out of disk space, but that is going to be a bad time with any database. It is not "competing for resources" when it is running the workload your app is sending it. You may as well say Sqlite is competing for resources in that case.

Re: Just use Postgres

#183
post #175

Earlier quoted context omitted.

> Depends on the environment or lack thereof, postgres is a pain in the ass on windows, and then you need support for software configuration so that it can talk to postgres, and then you have to take care of the features you're using. This is why everyone uses docker and .env files. The problem has already been solved and you can copy/paste starter files from project to project to make it a non issue.

Well running dbs in containers are generally not a good idea.

Works fine to enable developers, and most people use cloud database offerings like RDS in production.

Re: Just use Postgres

#184
post #18

> AI is a bubble why does it even matter? I know that I need multimodal search in my product, and that is why I need vector DB. You're not saying anything interesting by saying "AI is a bubble". If you say something like I may not actually need RAG/mutimodal/semantic search/dedicated vector db then you may have my attention.

Where does the funding for the companies developing those databases come from?

I do not know enough about vector search to assert pgvector is enough for you, but I do know enough about supply chains to get woozy

Re: Just use Postgres

#185

Earlier quoted context omitted.

I’ve heard stuff like this from supposedly senior people - if we use mongo we can just store anything, we don’t need to think about a schema (also you can only store short strings in an SQL database)

Good Lord the level of incompetence is terrifying

Most people dontgain competence until they learn from their mistakes

Re: Just use Postgres

#186

Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…

>> When data size goes to a billion rows, Postgres is tough. MongoDB just works without issue.

Our everyday problems... Tbh when you reach that size you will hopefully already have a dba department no matter what you use.

Re: Just use Postgres

#187
post #132

Earlier quoted context omitted.

The fact that you use Postgres-specific features extensively is a design decision that many people would never make, regardless of their trust in the engine.

That's like saying I use Rust but I don't want to use any Rust specific features because I might want to port it to Python someday. It's complete nonsense.

In the enterprise space, it isn't. You often have to build software that will run on different database back-ends. Just because your worldview doesn't align with other people's doesn't mean you own the truth...

Re: Just use Postgres

#188
For MySQL, for smaller deployments, I've found Galera to really be a handy HA system to get going:

> Galera Cluster is a synchronous multi-master database cluster, based on synchronous replication and MySQL and InnoDB. When Galera Cluster is in use, database reads and writes can be directed to any node. Any individual node can be lost without interruption in operations and without using complex failover procedures.

* https://galeracluster.com/library/documentation/overview.htm...

* https://packages.debian.org/search?keywords=galera

The closest out-of-box solution that I know of for Postgres is the proprietary BDR:

* https://www.enterprisedb.com/docs/pgd/4/bdr/

* https://wiki.postgresql.org/wiki/BDR_Project

There are systems like Bucardo, but they are trigger-based and external to the Postgres software:

* https://www.percona.com/blog/multi-master-replication-soluti...

Having a built-in 3-node MMR (or 2N+1arb[0]) solution would solve a bunch of 'simple' HA situations.

[0] https://packages.debian.org/search?keywords=galera-arbitrato...

Re: Just use Postgres

#189
post #15
post #8

Earlier quoted context omitted.

Why would you run Postgres on a different box in such a scenario? A docker run command to get a Postgres instance up and running isn’t any more complicated than linking in Sqlite, maybe even simpler. And you get proper ACID transactions for free.

1) Fault isolation in case of hardware failure 2) You may not even be able to _think_ about using Docker (OS restrictions, airgaps to install images, etc.) These are just 2 that come to mind from working in regulated industries.

I don't get the downvotes here. These are real world constraints.

Re: Just use Postgres

#190
post #40

> If you see a college student or fresh grad using MongoDB stop them. They need help. They have been led astray. I like this sentence way more than I should.

> They have been led astray. They haven't though. What's wrong with using a tool even if it might be bad? Especially as a fresh user. It's how we learn. From both good and bad experiences. > They need help. Sadly it's not the fresh grad, but the "experienced" that only keep their old experiences that need help. Is this comment from 2010? MongoDB has improved. Maybe not to the point of being the best but definitely no…

Some people think it’s them and double down with using a bad tool for the job.
Post reply on HN