Postgres Features

  1. It is available locally, in the clouds (as a managed service), in corporations (they know how to install and maintain it).
  2. Stable, fast, functional.
  3. Popular (documentation and people).
  4. It scales well for most tasks (most applications do not even dream of its performance and size limitations).

It seems to be perfect. Or not? Let’s look at other bases on the rumor.

Alternatives

  1. MySQL – GUI utilities are better, but otherwise worse in all characteristics. There is no point for new projects.
  2. Oracle/MSSQL – according to advertising statements, it seems to be better, but in practice no one really needs it for free, and even more so for serious money. If necessary, people know exactly why.
  3. MongoDB is a pretty popular thing, but you need to be very careful. Yes, initially it seems convenient: you don’t need to start any schemes, you just use it and that’s it. But the problem is that the server part must ensure the consistency of the data. Plus, suddenly there is an understanding that it is more difficult to make the structure of a document-oriented database, because it is necessary to think through use cases in advance, and in a relational one it is much easier to do this - it is usually enough to add indexes. In other words: it’s easy to start with Mongo (but I wouldn’t say it’s actually easier than with traditional databases), but then it gets harder and harder. If you do not need to scale the planetary level, then it is better not to mess with Mongo.
  4. Other databases - they are all niche. If it is clear that there is a good reason to use them, then why not, but usually as an additional storage, not the main one.

Hibernate aka JPA

Hibernate is worth mentioning separately – usually all the horrors of relational databases in the JVM world are caused by it.

Why? He promises too much and cannot fulfill his promises in principle.

Here again, Spring is trying to save everyone with Spring Data and their repositories, but it still relies on the same problematic basis. It did the same in Quarkus – they came up with Panache , but with the same problem – an already simple and adequate API relies on an inadequate monster.

If someone at the interview tries to ask a question about some difficult moments of Hibernate, then the answer is simple: in principle, you do not need to use it.

In one of the following notes, I will analyze the alternatives.

The result

Now it makes sense to start a new project on Postgres by default. At the same time, you do not need to use JPA/Hibernate and related technologies in any form.