Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just use Postgres

mccue.dev

Post reply on HN
Print view View original

91–100 of 238 posts

Re: Just use Postgres

#91

Post by philipwhiuk »

maipen wrote: post #82
endisneigh wrote: post #73

Use what you know, ship useful stuff.

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

Re: Just use Postgres

#92

Post by yigitcan07 »

I've found out key/value databases pushes for better architectural designs in enterprise environments. Especially in companies where different teams are responsible for a given business capability and it needs to scale above 1+ million users.

Postgres flexibility enables for design that is hard to scale. Both in terms of maintainability and performance. Enforcing K/V as a default database in one of my previous companies worked wonders.

Re: Just use Postgres

#94

Post by mortehu »

ginko wrote: post #80

I wish postgres had a library only mode that directly stored to a file like sqlite. That'd make starting development a lot easier since you don't have to jump through the hoops of setting up a postgres server. You could then switch to a "proper" DB when your application grows.

It's literally 4 lines of Python code calling subprocess.Popen to start a PostgreSQL server for a given database directory and connecting to it via a pipe on the filesystem. However, you can't launch multiple concurrent instances like this.

Re: Just use Postgres

#95

Post by christophilus »

For everyone saying, “Just use SQLite”, how do you deal with pathological queries causing a denial of service? SQLite is synchronous, so you end up blocking your entire application when a query takes a long time. It’s a problem in Postgres, too, especially if the query involves table locks, but your app can Postgres can generally hobble along.

Re: Just use Postgres

#96

Post by arpinum »

Rastonbury wrote: post #87
arpinum wrote: post #56

Earlier quoted context omitted.

This sentence has no substance. It gives the reader nothing to understand why MongoDB has both happy customers some who have been disappointed.

The explanation is in the paragraph before it

except its factually incorrect when applied to Mongo[1].

[1] https://news.ycombinator.com/item?id=41273563

Re: Just use Postgres

#97

Post by poorlyknit »

StefanBatory wrote: post #19
andrewstuart wrote: post #6

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…

May I ask question about this part? "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!" From my courses I had at university, I've been led to believe that the current trend is doing hexagonal architecture, as that allows for better modularisation of the project and helps keep code clean over ma…

Not OP, but I think it's a valid approach.

You gain: Model consistency guaranteed by the database, your backend basically only acts as an external API for the database.

You lose: Modularity, makes it harder to swap out databases. Also, you have to write SQL for business logic which many developers are bad at or dislike or both.

I've seen a system running on this approach for ten years and it survived three generations of developers programming against this API. There's Python wx frontends, web frontends, Rust software, Java software, C software, etc. They all use the same database procedures for manipulating the model so it stays consistent. Postgres is (kinda, not very) heavy for small projects but it scales for medium up to large-ish projects (where it still scales but not as trivially). One downside I've seen in this project is that some developers were afraid to change the SQL procedures so they started to work around them instead of adding new ones or changing the existing ones. So in addition to your regular work horse programming language you also have to be pretty good at SQL.

Re: Just use Postgres

#98

Post by cloogshicer »

viraptor wrote: post #37
cloogshicer wrote: post #23

Earlier quoted context omitted.

Surprised to hear that losing 15 min of state is not a big deal in a banking context. I haven't worked with banks before, genuinely curious, how do they recover from something like this? Wouldn't this potentially destroy all transactions made in that time period?

To be fair they said "frontline application", not a transaction processor specifically. Also in cases where you can't lose stuff it's common to use reliable steam processing, so maybe they can reprocess old events into the system running sqlite. (This is extra general info about "important systems"; I don't know what OP is running)

Ah, maybe I just don't know what "frontline application" means in this context.

Re: Just use Postgres

#99

Post by nu11ptr »

I don't hate SQL and I agree for many applications it makes sense, but I disagree 100% with "default to a SQL database" (like Postgres). Instead, figure out what you need based on your app.

Recently I had the opportunity to rewrite an application from scratch in a new language. This was a career first for me and I won't go into the why aspect. Anyway, the v1 of the app used SQL and v2 was written against MongoDb. I planned the data access patterns based on knowledge that my DB was effectively document/key/value. The end result: it is much simpler. The v1 DB had like 100+ tables with lots of relations and needs lots of documentation. The v2 DB has like 10 "tables" (or whatever mongo calls them) yet does the same thing. Granted, I could have made 10 equivalent SQL tables as well but this would have defeated the purpose of using SQL in the first place. This isn't to say MongoDB is "better". If I had tons of fancy queries and relations I needed it would be easier with SQL, but for this particular app, it is a MUCH better choice.

TL;DR Don't default to anything, look at your requirements and make an intelligent choice.

Re: Just use Postgres

#100

Post by CuriouslyC »

masklinn wrote: post #61
Kiro wrote: post #38

When people say "Just use SQLite. It's almost as good as Postgres and you won't need anything more" I'm trying to understand why I shouldn't just use Postgres. It's not like it's hard to install or has any significant overhead. Please enlighten me.

> It's not like it's hard to install or has any significant overhead. 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. If you're deploying a complex server-side system with lots of moving parts, then yes postgres is basically free. But…

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

Post reply on HN