Live data from Hacker News

PostgreSQL for Everything

raphaelbauer.com

281–286 of 286 posts

Re: PostgreSQL for Everything

#281

Earlier quoted context omitted.

it's not the way to go if you hit the limits very quickly and have to waste immense time migrating.

From my experience the limits are way higher than people think.

from my experience they're actually much lower than people think, especially when using Postgres for things it's not well-suited for like queuing, and the problem is you rarely can just throw more hardware at it to solve the problem and it's really not a good place to be.

Re: PostgreSQL for Everything

#282
post #121

Earlier quoted context omitted.

There are two sizes of companies: those that can afford '1+ dedicated ____-person' and those that can't. Which should filter through to technology choices more than it does.

Or, you can do like one of my former bosses, and just rattle off a list of 60+ major projects which would require a team of 10 to make any reasonable progress on in the near future, then pin it on one underqualified person, refuse to provide a proper budget, and continually press them about why targeted deadlines are being missed.

Organization, in that hypothetical, the individual also retains substantial power.

Enough so that they should sit their boss down and say 'I have capacity for N of these projects, let's rank them in terms of priority.'

Re: PostgreSQL for Everything

#283
post #273

There's a missing essay: Postgres for nothing. A tiny store on SQLite/D1 with no admin UI is boring and it stays up. The day I need JSONB I'll know.

> A tiny store on SQLite/D1 with no admin UI is boring and it stays up. D1?

https://www.cloudflare.com/products/d1/

Re: PostgreSQL for Everything

#284
post #282

Earlier quoted context omitted.

Or, you can do like one of my former bosses, and just rattle off a list of 60+ major projects which would require a team of 10 to make any reasonable progress on in the near future, then pin it on one underqualified person, refuse to provide a proper budget, and continually press them about why targeted deadlines are being missed.

Organization, in that hypothetical, the individual also retains substantial power. Enough so that they should sit their boss down and say 'I have capacity for N of these projects, let's rank them in terms of priority.'

You would think so! Perhaps in a more sane situation. We tried it and it did not help. Priorities shifted, facts on the ground changed, emergencies came up, and there was almost no chance to focus for long periods.

Part of it was me not handling certain kinds of stress well, but a different management approach absolutely could have made a difference. To cut them a bit of slack, this particular boss had come from a prior position where they were managing hundreds of roles... to a small shop where they managed just a handful (and only one other dedicated IT person). They had trouble breaking away from the "throw everything at the wall and go full steam on it all" approach and dealing with scarce resources more carefully.

Re: PostgreSQL for Everything

#285

Earlier quoted context omitted.

> I don't think that's ever saved money. I spent about a year as a consultant in the AWS space, visited about ~15 clients of varying sizes. More often than not there's a single pg aurora instance responsible for 50%+ of the bill. Even worse are the serverless aurora offenders. All the indexes and guarantees of PG don't come cheaply and dynamodb pricing is not cheap but comparatively reasonable. It really is a good pr…

> All the indexes and guarantees of PG don't come cheaply I’m currently paying digital ocean about 30 dollars a month for 4 commercial websites with fully featured Postgres.

I would be framing my comments around enterprise architecture. For one off websites, cheaper on digital ocean is always the winner.

Re: PostgreSQL for Everything

#286
post #276

Earlier quoted context omitted.

> Postgres does not even come close to a full replacement for Elastic Size matters! For most of the application out there elastic (or kafka or any other specialized tool) is just too much(and too costly). They can do fine with postgres or mysql. Actually, I'd argue that in a lot of cases even postgres is too much, probably sqlite is enough.

What do you know about full text search? Faceted search? Custom tokenization? It is wild to see people talk about Postgres fulltext like it’s all you could need, even for small apps.

I didn't say that is "all you could need", I said is "just fine for a lot of use cases out there", which implies that there are use cases where you could need specialized tools ...
Post reply on HN