Live data from Hacker News

Just use Postgres

mccue.dev

131–140 of 238 posts

Re: Just use Postgres

#131
post #28

Earlier quoted context omitted.

I don’t. How are new grads supposed to learn the ups and downs of different choices they make? Just being told they’re led astray in a blog post isn’t gonna work - it’ll backfire. I used node as a new grad for things it wasn’t meant for and that’s how I learned what it is good at and what it isn’t.

It's OK to use anything in personal or throw-away projects. But if your choices might cause big losses, it's better to avoid experimental technologies. "Nobody was fired for choosing IBM" is a known meme, but it's not just meme, it's actually solid advice (not specifically about IBM).

You are basically referring to the "Boring Technology Club" [1] by @mcfunley.

[1]: https://boringtechnology.club/

Re: Just use Postgres

#132
post #5

The "SQLite is just a file" thing is actually an advantage. The example of a website is actually a pretty poor one, since any website that needs to scale beyond a single box has many options. The two easiest ones are: - Mix static and dynamic content generation (and let's face it, most websites are mostly static from a server perspective) - Designate a writer node and use any of the multiple SQLite replication featur…

> if you use an ORM that supports both SQLite and Postgres you'll have the option to upgrade if your site brings in enough traffic I'll never understand this idea that Postgres and SQLite are somehow interchangeable when the time is right. My database and Postgres are _literally_ the core definition of everything that my application does. My app is written in Rust, but that doesn't matter because it's a _Postgres_ ap…

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.

Re: Just use Postgres

#133
post #54

Totally agree - I have tried many databases of all flavors, but I always come back to Postgres. HOWEVER - this blog post is missing a critical point.... the quote should be: ---> Just use Postgres AND ---> Just use SQL "Program the machine" stop using abstractions, ORMs, libraries and layers. Learn how to write SQL - or at least learn how to debug the very good SQL that ChatGPT writes. Please, use all the very powerf…

Stored procedures suck. First of all SQL is a dubious language to write business logic in because it doesn’t have static typing and other goodies we expect nowadays. But more importantly stored procedures tend to drift out of version control. So please don’t.

>> tend to drift out of version control

Old wives tale.

Modern IDEs are very good at version control over all database elements.

https://www.jetbrains.com/help/datagrip/databases-in-the-ver...

Re: Just use Postgres

#134
post #132

Earlier quoted context omitted.

> if you use an ORM that supports both SQLite and Postgres you'll have the option to upgrade if your site brings in enough traffic I'll never understand this idea that Postgres and SQLite are somehow interchangeable when the time is right. My database and Postgres are _literally_ the core definition of everything that my application does. My app is written in Rust, but that doesn't matter because it's a _Postgres_ ap…

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.

Re: Just use Postgres

#135
post #93

> Why not MySQL? MySQL is owned by Oracle. Ok, so what about MariaDB?

Still nowhere near Postgres from my experience, full of nasty surprises like arbitrary missing features and weird defaults.

Re: Just use Postgres

#136
post #55
post #40

Earlier quoted context omitted.

> 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…

> Especially as a fresh user. It's how we learn. From both good and bad experiences. I'd do that, but a superior strategy is letting other people make mistakes and then learning from them. It is best to always be making choices that seem like they could be optimal, with very rare exceptions.

> but a superior strategy is letting other people make mistakes and then learning from them

If this was a superior strategy that was so obvious no 1 would be making mistakes so how does this work? Not everything is strictly better.

And by that logic...

>> the superior strategy is letting other people comment (and make mistakes) and then learn from them

i.e. don't read the post until years later to ensure you have all the mistakes and learnings. Sorry, this thread is still live.

Re: Just use Postgres

#137
post #5

The "SQLite is just a file" thing is actually an advantage. The example of a website is actually a pretty poor one, since any website that needs to scale beyond a single box has many options. The two easiest ones are: - Mix static and dynamic content generation (and let's face it, most websites are mostly static from a server perspective) - Designate a writer node and use any of the multiple SQLite replication featur…

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...

Re: Just use Postgres

#138
post #82

Earlier quoted context omitted.

I agree. Mariadb is one of the easiest dbs i have ever used. Easy to setup and flexible. I prefer to use whatever makes it quicker to build something, which usually means whatever I am experienced with already. Building products is what’s important at the end of the day. No body cares, nor should they, what kind of tools Michael Angelo used. His art is what we value.

> Michael Angelo Michaelangelo was his first name. His full name is Michelangelo di Lodovico Buonarroti Simoni

Like Leo Nardo, Don E. Telli and Raph A. El. All masters of their chosen marital arts.

Re: Just use Postgres

#139

> 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.

Fully agree. At that level, the justification for using MongoDB usually boils down to not wanting to deal with table schemas or SQL. In both cases, there are better alternatives.

> not wanting to deal with table schemas or SQL.

In most cases you're not even removing the concept of the schemas, your just moving them from your database to your application. Which in a sense is worse, especially if multiple applications needs to access the same database.

As for SQL, I have yet to see something solve the problem for querying a database in a simpler manor.

Re: Just use Postgres

#140

> 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.

Exactly, SSPL is such a trojan horse, and God knows how they will change the license in the future

That’s not remotely the point.
Post reply on HN