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

41–50 of 238 posts

Re: Just use Postgres

#41

Post by re-thc »

rcarmo wrote: 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…

> The "SQLite is just a file" thing is actually an advantage.

It's more like besides the point. Everything in Linux is "just a file".

Re: Just use Postgres

#42

Post by viraptor »

tormeh wrote: post #13

MySQL is like Javascript: Full of bad decisions and footguns. It works perfectly fine, but I don’t see why you’d use it when Postgres exists.

Depends on your workload, immutable tuples and vacuum can hurt a lot. (Although that got much better recently) Also the mad decisions about the query planner which you can't control. Often this doesn't matter, but it's worth being aware.

Re: Just use Postgres

#43

Post by tytho »

kingkongjaffa wrote: post #21

Does anyone know why seemingly all the introductory courses advocated nosql stuff like using mongoDB Even freecodecamp who is excellent, does this. They have a rel-db course https://www.freecodecamp.org/learn/relational-database/ but their backend course uses mongodb https://www.freecodecamp.org/learn/back-end-development-and-...

I can’t speak to the official decisions made by these camps/courses, but from my own experience as an undergrad, I was first introduce to MySQL, and the professors at my university did not teach using migration management tools for bringing a schema in a database up. You were either using a GUI to set up the tables, or running your own cobbled together sql files. For class assignments this was fine. Then I had a professor introduce mongo to me. I was floored by the idea of having my schema live along-side the application code! No more messing around in SQL GUIs! Then of course over time I realized you still need to maintain a schema over time and provide someway to “upgrade” data when your schema evolves, and keep your data consistent. Then I discovered the tools around migrating mongo data are not nearly as mature as the ones you’ll find for SQL databases.

I find mongo alright at producing a short-lived prototype of an application (e.g. school assignments), but the risk of it shipping to production for a long period is too risky for the “benefit”.

Re: Just use Postgres

#46

Post by arpinum »

worik wrote: post #35
arpinum wrote: post #10

It's not worth pointing out the technical flaws in the post[1]. It is obvious the author does not have a strong grasp of the tools he is criticising. A better example of this style of post is Oxide's evaluation[2] for control plane storage that actually goes over their specific needs and context. [1] Ok, just one, Rick Houlihan is currently at MongoDB. [2] https://rfd.shared.oxide.computer/rfd/53

> Rick Houlihan is currently at MongoDB. Not according to the YT video. AWS in 2018 I did not detect technical flaws in the article. I thought it was very good

[flagged]

Re: Just use Postgres

#48

Post by Gud »

KingOfCoders wrote: post #2

Postgres will do to other databases, what Linux did to other Unix(/BSD-like) operating systems (IRIX, SunOs, ...).

Linux didn’t “do” anything to *BSD. Linux emerged at the same time there was a nasty lawsuit against BSD.

Re: Just use Postgres

#49

Post by tetha »

On the MySQL vs Postgres topic: We migrated for two reasons.

The first is that I consider everything remotely owned by Oracle as a business risk. Personal opinion and maybe too harsh, but Oracle licenses are made to be violated accidentially so you can be sued and put on the license hook once you're audited, try as you might.

But besides that, Postgres gives you more tools to keep your data consistent and the extension world can save a lot of dev-time with very good solutions.

For example, we're often exporting tenants at an SQL level and import somewhere else. This can turn out very weird if those are 12 year old on-prem tenants. MySQL in such a case has you turn of all foreign key validations and whatever happens happens. A lot of fun with every future DB migration is what happens. With Postgres, you just turn on deferred foreign key validation. That way it imports the dump, eventually complains and throws it all away. No migration issues in the future.

Or the overall tooling ecosystem around PostgreSQL just feels more mature and complete to me at least. HA (Patroni and such), Backups (pgbackrest, ...), pg_crypto, pg_partman and so on just offer a lot of very mature solutions to common operational and dev-issues.

Re: Just use Postgres

#50

Post by refset »

If Postgres already had decent temporal table support (per SQL:2011 system time + application time "bitemporal" versioning) we never would have gone down the road of building XTDB. From the perspective of anyone building applications on top of SQL with complex reporting requirements in heavily regulated sectors (FS, Insurance, Healthcare etc.), "just use temporal tables" would be the ideal default choice. To get an idea of why, see https://docs.xtdb.com/tutorials/financial-usecase/time-in-fi...
Post reply on HN