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

PostgreSQL is enough

gist.github.com

Post reply on HN
Print view View original

11–20 of 323 posts

Re: PostgreSQL is enough

#11

Post by jerrygenser »

CraigJPerry wrote: post #7

Aspiring to "use the right tool for the job" leads you into conflict with some of the ideas posted on the gist. To give a concrete example on the first item in the gist: if i need periodic jobs - and all the operational headaches that go with (rerunning, ordering, dependencies, logging, yada yada...) - is postgres the right tool for the job? It CAN be, but for most people in most circumstances, it's probably not.

If the purpose is to do database specific things then pg cron can be useful for e.g. periodic vacuums. However for running application logic, maybe less so.

Re: PostgreSQL is enough

#12

Post by kevinmershon »

Thank you for this post. I've been looking high and low for weeks trying to find a way to connect Looker to a GraphQL API unsuccessfully and apparently "PostgreSQL emulators" are called FDWs as I learned from this link. I had searched every term I could think of for how to simulate or proxy a SQL database into an API but calling it a foreign data wrapper would have never occurred to me.

Re: PostgreSQL is enough

#13

Post by karmakaze »

wesselbindt wrote: post #3

Seems like it's less than a week ago that someone (rightly) posted that it isn't [1]. Postgres is a relational database, and it does this really well. It's not a convection oven. [1] https://news.ycombinator.com/item?id=39243655

That is specifically about AWS/RDS and relates to EBS/IOPS moreso than PostgreSQL. In fact their solution was to run the db but not as an RDS instance.

> The Solution: Roll your own: For us the solution was fairly simple: don’t use a managed database services and roll our own infrastructure on EC2.

I've done the same running PostgreSQL on EC2 instances with NVMe local raid storage. It's very fast, but then you're responsible for its uptime, updates, backups, etc. That setup was used for performance sensitive but less critical data.

Re: PostgreSQL is enough

#14

Post by nahnahno »

wesselbindt wrote: post #3

Seems like it's less than a week ago that someone (rightly) posted that it isn't [1]. Postgres is a relational database, and it does this really well. It's not a convection oven. [1] https://news.ycombinator.com/item?id=39243655

Did you read the article? It’s about how expensive RDS is, not about how Postgres didn’t work.

Re: PostgreSQL is enough

#15

Post by jjice »

benrutter wrote: post #8

On the [Simplify: move code into databases]( https://sive.rs/pg ), has anyone actually tried this? My instinct is that the output won't be simpler at all, but a big twisty web of varying parts and competing use cases, all extremely hard to discover. To me, having two things that do something distinct is simpler, and ironically, Rich Hickey says this exact thing in Simplicity Matters, which is quoted in the article.

> To me, having two things that do something distinct is simpler

I completely agree. Inside the DB, it's hard to argue about performance benefits in a lot of situations. That said, debugging, testing, and developing are so much harder. I love to have a well written bit of code that I can integration test as well as mock up and use for unit tests with other components of my application. It's much trickier to do that in the DB. Sometimes it is a lot more performant, and that's a situation you may want to consider moving towards, but I would try to stay away from it for as long as the performance gain isn't huge.

Re: PostgreSQL is enough

#16

Post by macksd »

twosdai wrote: post #6
superb-owl wrote: post #2

I often go down rabbit holes like this, trying to collapse and simplify the application stack. But inevitably, as an application grows in complexity, you start to realize _why_ there's a stack, rather than just a single technology to rule them all. Trying to cram everything into Postgres (or lambdas, or S3, or firebase, or whatever other tech you're trying to consolidate on) starts to get really uncomfortable. That s…

The same argument of UNIX design patterns (Single responsibility, well defined interfaces and communication protocals) vs Monolithic design patterns comes up a lot. I think that its mainly because both are effective at producing products, its just that they both have downsides.

I read a meme yesterday about how you can just interject "it's all about finding that balance" into any meeting and people will just agree with you. I'm gonna say it here.

Sometimes a flexible tool fits the bill well. Sometimes a specialized tool does. It's all about finding that balance.

Thank you for coming to my TED talk.

Re: PostgreSQL is enough

#18

Post by e12e »

twosdai wrote: post #6
superb-owl wrote: post #2

I often go down rabbit holes like this, trying to collapse and simplify the application stack. But inevitably, as an application grows in complexity, you start to realize _why_ there's a stack, rather than just a single technology to rule them all. Trying to cram everything into Postgres (or lambdas, or S3, or firebase, or whatever other tech you're trying to consolidate on) starts to get really uncomfortable. That s…

The same argument of UNIX design patterns (Single responsibility, well defined interfaces and communication protocals) vs Monolithic design patterns comes up a lot. I think that its mainly because both are effective at producing products, its just that they both have downsides.

Just noting that sometimes one can do both: seperate postgres DBs/clusters for different use-case, seperate instances of a web server for TLS termination, caching, routing/rewriting, Ed:static asset serving. Benefit is orderly architecture, and fewer different dependencies.

Re: PostgreSQL is enough

#19

Post by diggan »

superb-owl wrote: post #2

I often go down rabbit holes like this, trying to collapse and simplify the application stack. But inevitably, as an application grows in complexity, you start to realize _why_ there's a stack, rather than just a single technology to rule them all. Trying to cram everything into Postgres (or lambdas, or S3, or firebase, or whatever other tech you're trying to consolidate on) starts to get really uncomfortable. That s…

I think a lot of the industry struggles with the idea that maybe there is no "one size fits all", and what makes sense when you're a one person company with 100 customer probably doesn't make sense when you're a 1000 people company with millions of customers.

If you use a stack meant for a huge userbase (with all the tradeoffs that comes with it) but you're still trying to find market fit, you're in for a disappointment

Similarly, if you use a stack meant for smaller projects while having thousands of users relying on you, you're also in for a disappointment.

It's OK to make a choice in the beginning based on the current context and environment, and then change when it no longer makes sense. Doesn't even have to be "technical debt", just "the right choice at that moment".

Post reply on HN