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

271–280 of 323 posts

Re: PostgreSQL is enough

#271

Post by edwardsdl »

bun_terminator wrote: post #113
afandian wrote: post #109

Earlier quoted context omitted.

It's a narrow use-case that doesn't cover RDMS. SQLite fits it though.

The first thing I did was ask why we don't use sqlite or at least postgres. The answer was that they are free and therefore we don't trust them. So Oracle it is. Which is bananas because our customers have to buy an oracle license, which is money that we don't get. Pretty wild

> The answer was that they are free and therefore we don't trust them.

If you don’t mind a bit of unsolicited advice: run.

Re: PostgreSQL is enough

#272

Post by randomdata »

sgarland wrote: post #262
randomdata wrote: post #260

Earlier quoted context omitted.

> Joins are not a "hack," they are an integral part of the relational model. Yes, joins are an essential part of the relational model, but we're clearly not talking about the relational model. The n+1 problem rears its ugly head when you don't have a relational model – when you have a tree-like model instead. > The included query in the gist returns all available information about the albums present in a single query…

n+1 can show up any time you have poorly modeled schema or queries. It’s quite possible to have a relational model that is sub-optimal; reference the fact that there are 5 levels of normalization (plus a couple extra) before you get into absurdity. I still would like to know how SQLite does not suffer from the same problems as any other RDBMS. Do you have an example schema?

> I still would like to know how SQLite does not suffer from the same problems as any other RDBMS.

That's simple: Not being an RDMBS, only an engine, is how it avoids the suffering.

The n+1 problem is the result of slow execution. Of course, an idealize database has no time constraints, but the real world is not so kind. While SQLite has not figured out how to defy the laws of physics, it is able to reduce the time to run a query to imperceptible levels under typical usage by embedding itself in the application. Each query is just a function call, which are fast.

Postgres' engine can be just as fast, but because it hides the engine behind the system layer, you don't interact with the engine directly. That means you need to resort to hacks to try and poke at the engine where the system tries to stand in the way. The hacks work... but at the cost of more complexity in the application.

Re: PostgreSQL is enough

#273

Post by bun_terminator »

edwardsdl wrote: post #271
bun_terminator wrote: post #113

Earlier quoted context omitted.

The first thing I did was ask why we don't use sqlite or at least postgres. The answer was that they are free and therefore we don't trust them. So Oracle it is. Which is bananas because our customers have to buy an oracle license, which is money that we don't get. Pretty wild

> The answer was that they are free and therefore we don't trust them. If you don’t mind a bit of unsolicited advice: run.

I mean you do a job because of the pay, not because you like the people or they are particularly competent. So it's a good gig for two years or so

Re: PostgreSQL is enough

#274

Post by edwardsdl »

bun_terminator wrote: post #273
edwardsdl wrote: post #271

Earlier quoted context omitted.

> The answer was that they are free and therefore we don't trust them. If you don’t mind a bit of unsolicited advice: run.

I mean you do a job because of the pay, not because you like the people or they are particularly competent. So it's a good gig for two years or so

I’ve found that surrounding myself with competent people - or better yet, people far better than me - has lead me to much better paying jobs.

Re: PostgreSQL is enough

#275

Post by randomdata »

Ensorceled wrote: post #259
randomdata wrote: post #228

Earlier quoted context omitted.

1. At time of writing, there has been one downvote in the first comment, followed by one upvote in the subsequent comment. Not only does that not translate to "a lot of people", it was quite likely just one person. And unless that person was you, it is impossible to know what their intent was. I'm not sure what are you trying to add here. 2. Who gives a shit? If the "computers truly are magic" camp don't understand w…

> Who gives a shit? [...] I'm not sure what you are trying to add here. I guess nothing. You must be fun at design reviews.

Well, let's hope the "computers are magic" riff-raff never show up at the design reviews. Especially if they expect someone to explain to them the basics of computing without any reasonable offer of compensation in return.

If those people show up here and put on a tantrum by pressing random buttons or whatever it was that you were trying to point out... Oh well? I wouldn't have even noticed if you didn't bring it up.

What value you found in calling attention to their pointless tantrums is an interesting mystery, though!

Re: PostgreSQL is enough

#277

Post by zwnow »

LaGrange wrote: post #96
zwnow wrote: post #81

Earlier quoted context omitted.

Honestly, that's one of the reasons I never want to monetize my work and stay miles away from the software industry. Modern world is all web apps that require you to subscribe to 20 different 3rd party services to even build your app. So you rack up bills before your product is even remotely lucrative... Building an app with no third party dependencies seems impossible nowadays. At least if you plan to compete.

I mean, you _can_ host your staging environment on a Minisforum PC hidden in your closet and then deploy to Hetzner, and probably save a _ton_ unless your service benefits from things like, say, autoscaling or global low-latency access. Niches where you can get away with that are limited, not just by technical challenges but because large parts of the social ecosystem of IT won't like that. But they do exist. There's…

Yea I mostly learned web dev so far but wanted to get into IoT stuff so I might find something cool to do in there.

Re: PostgreSQL is enough

#278

Post by int_19h »

throwawaaarrgh wrote: post #114

If you twist yourself into a pretzel enough you can make Bash do all these things. Doesn't make it a good idea. The biggest problem with depending on Postgres is it's a large complex monolith. Any problem you have only has two possible solutions: 1) spend a ton of time trying to twist yourself into a more pretzely shape to get it to do what you want, or 2) replace that thing you wanted with some external thing. Both…

Given how things look in, say, the Node.js ecosystem, a large complex monolith has its attractions - chiefly that it doesn't fall apart at you, because it wasn't cobbled together with duck tape.

It also has the benefit that it's a stable solution that has been around for decades, and will likely be around for just as long. Meaning that you won't have to constantly rewrite and update things to keep up with whatever the developers of your favorite framework decided is the Right Way to do things this year.

Re: PostgreSQL is enough

#279

Post by dventimi »

jgalentine007 wrote: post #152
cpursley wrote: post #145

Earlier quoted context omitted.

Handling business logic in the database is often going to be an order of magnitude faster than the application layer of some of the popular language stacks (looking at you, Rails, Node, etc). It also will outlive whatever webstack of the day (and acquisition which of en requires a re-write of the application layer but keeps general database structure - been there done that).

Maybe faster... but I've met very few developers that are good DBAs (that understand procedures, cursors, permissions etc.) Database schema versioning / consistency is a whole other level of pain too.

That sounds like a social problem, not a technical problem.

Re: PostgreSQL is enough

#280

Post by rrr_oh_man »

emseetech wrote: post #204
Ensorceled wrote: post #192

Earlier quoted context omitted.

I guess that's really my point here. They difference in setup time is negligible so I'm not sure why people keep bringing it up as a reason to choose sqlite over PostgreSQL. For instance, "deployable inside a customer application" is an actual requirement that would make me loath to pick PostgreSQL. "Needs to be accessible, with redundancy, across multiple AWS zones" would make me very reluctant to pick sqlite. Neith…

> Needs to be accessible, with redundancy, across multiple AWS zones How many projects start with these requirements?

> How many projects start with these requirements?

In a world fueled by cheap money and expensive dreams, you'd be surprised.

Post reply on HN