From your experience, does TypeORM in Nest work better with MySQL or Postgres? I am starting a new project and can't decide which DB should I go with Nest. I haven't used Nest before outside of tutorials - and they used Prisma there ;D So... perhaps we can include the possibility of using Prisma as well. So, would it be different with Prisma? The web and mobile apps will be doing mostly reads and not a lot of writes.
#Does Nest with TypeORM (or Prisma) work better with MySQL or Postgres?
strong yew
brazen prism
You will most likely see no difference unless your app serves bajilions of users at the same time. But I'd say go-to db of today is postgres
strong yew
Do you use Postgres? What about memory leaks? As I understand databases both MySQL and Postgres can set up some upper limit e.g 1.5 gb RAM max. when you are on a server with 4GB for the whole Ubuntu 22.04 system. But it seems that people say that MySQL is easier to setup in this way and it is better at serving more reads with the same amount of RAM. Postgres seems to be harder to configure and not as well suited for environments with low RAM etc. But perhaps when you put Node into the question and the quality of pg vs mysql/mysql2 drivers it is in fact in favor of Postgres.
I just know that the driver for Postgres is much worse on PHP. And the MySQL driver is absolutely tuned out and perfected and the MySQL and PHP workflow is much better than Postgres and PHP workflow, from the req/s to implementation and docs and community etc.
But I have no idea what is the situation in the Node.js world. By having two mysql drivers implementation in use (mysql and mysql2), it seems that pg driver is more pferred and hence more finetuned by bigger community and that, in fact, the Postgres + Node/Nest combination is better than Node/Nest with MySQL?
What do you (or other Node/Nest people) think about this?
brazen prism
Don't think too much and just pick one. Postgres is more common in the node world. Databae choice is a detail that does not matter at all for a proof of concept app. You can always change it later (provided you don't hardcode database-specific code in your app)
deep thorn
If you're super concerned about it, make a small proof of concept and try them both out.
I personally use postgres with docker-compose and it's dead simple to set up. I only really use MySQL when someone comes to me with a reproduction that has it
strong yew
If you're super concerned about it, make a small proof of concept and try them b...
But you haven't made a benchmark, right?
strong yew
Don't think too much and just pick one. Postgres is more common in the node worl...
I am not making a proof of concept app. Also I did quite a lot of PHP + MySQL stuff. That's why I am asking about Postgres. It's interesting that the benchmarks for this thing are impossible to find and it's mostly "trust me bro" or "do whatever you want" type of responses. 😉
From my personal experience with Postgres - it feels quite heavy so far. But I will try to use it more. I am not sure about the amount of processes Postgres spawns in your system. But perhaps it's better than MySQL's way of doing things.
deep thorn
But you haven't made a benchmark, right?
Personally, no. I haven't looked deeply into the performance difference between MySQL and Postgres. I'm sure there exists benchmarks though
brazen prism
As with most things in tech - this is something that does not really matter that much. Everybody just wants to sell you their solution and most benchmarks are skewed and don't reflect the real usage at all. So, as a responsible software developer, you should just pick one and start coding, but architect your app in a way that it's easy to swap it for a different implementation if the need comes.
You can date any tech all you want, but if you marry it, then dumping it would be much harder later on.
And this applies to frameworks as well 😉 The most important parts of your app (I.e. the business logic) should be independent of any framework or 3rd party library code (or at least separable with minimal effort)
strong yew
Yeah, theory is nice, but reality is different. What is a prototyping mockup will end up as a shipping product. The rewrite won't happen 😉 That's why knowing as much info up front is nice.
deep thorn
Honestly, with a good abstraction, it should be easy enough to swap out between postgres or mysql at least for testing purposes. Just depends on how the abstraction is written 😉
brazen prism
Most ORMs let you change the database on the fly. Just make sure you don't depend on any database specific features.
brazen prism
Yeah, theory is nice, but reality is different. What is a prototyping mockup wil...
I know that reality is different, you can't always code in a way that everything is changeable. BUT, arcitecting the app that most 3rd party dependencies are interchangeable is not an unattainable task. The trick, as jmcdo said, is to put them behing your abstractions that you have 100% control over. Most examples you can find online don't do that at all though. If your prototype ends up being shipped to prod (which is sadly a likely scenario), there should still be a time allowed for a proper refactor. Not allowing for that will be the products demise.
craggy dirge
will what u think is much better as an orm for postgres ( Typeorm or prisma) something to be much popular and better choice ??
brazen prism
@craggy dirge #1156124199874732033 message