I have recently come across a concept of transactions. Seems like they are a crucial feature for production applications, yet I have never heard about them except once in a university. I can't remember a single tutorial on youtube / udemy that actually manipulated with db using transactions.
Maybe if so few people talk about it, it (now) happens (somehow) automatically? Do I have to implement it explicitly to make my db consistent? I use postgresql.
Transactions are important for situations where you have multiple clients attempting to read/write the database at the same time. Andrew's answer also makes the point about grouping statements together. Depending on how you are accessing the database, transactions might be happening at an API-level where you are not aware of it. I think some ORM frameworks will automatically wrap your statements in transactions. Some databases can also operate in a "auto-commit" mode where every statement gets wrapped in a transaction at the database level.
You might not have seen a tutorial on them as some people might consider them an "advanced" topic, beyond basic DML/DDL statements, but I can assure you, they are very important, and it's good that you're taking the time to learn about them, even if you don't need to code them explicitly in your current project.
For interest's sake: I searched "postgres transaction tutorial" and discovered this: https://www.tutorialspoint.com/postgresql/postgresql_transactions.htm - but it's not a YouTube video.
Transactions are also important when a group of changes must be treated as a coherent set: either all of the changes must be applied, or none of them.
If you don't use transactions in cases like that, if any update or insert after the first fails for some reason, the previous updates or inserts would remain.
If all updates or inserts in a set are done in a transaction, if any updates or inserts fail, the entire transaction can be rolled back and the database will be as if none of the updates or inserts ever happened.
Even software running just on your home laptop should/will use transactions. For example, your software decides that one value in the database is increased, and another is decreased by the some amount, and then the whole operation is removed from a task list in the database.
You make that a transaction so if the software crashes you will have either no change or all three changes in the database. Not just the first change or the first two changes. So if you restart the app after the crash, either the whole operation has been performed and is gone from the task list, or the operation is still in the task list and you can repeat it.
Without transactions you might find yourself in a situation where the increase has happened but not the decrease, or both have happened but the operation is still in the task list and you do it twice. Lots of opportunities to mess up your database.
Full ACID transactions are extremely important to ensure that your data is always consistent. All mature Relational Database Management Systems (RDBMS) support them, and PostgreSQL is not an exception (good choice).
The drawback of ACID is that it can slow down your application to provide those guarantees, so some RDBMS don't support them or they are disabled by default. If by DB you are also referring to the NoSQL products like MongoDB, be aware that they are using concepts like "eventual consistency" which basically means no full ACID guarantees. Depending on your application and how critical your data is, it is up to you to decide what suits you best.
