This article is a book review for the Just Use Postgres! book by Denis Magda, which I totally recommend you read.

Vlad Mihalcea's blog offers insights into software development, database technologies, and Java programming. Readers can explore articles covering topics such as Hibernate ORM, SQL optimization, and high-performance database architectures. Additionally, they can learn about best practices for building scalable and efficient Java applications.

Vlad Mihalcea

A comprehensive review of Denis Magda's book covering PostgreSQL's capabilities beyond traditional relational features. The 402-page guide explores core database concepts like indexing (B+Tree, hash, partial), transactions, and modern SQL features (CTEs, window functions), then dives into non-relational capabilities including JSON storage and full-text search. The book examines PostgreSQL's extension ecosystem: pgvector for ML/GenAI embeddings, TimescaleDB for time series data, PostGIS for geospatial queries, and pgmq for message queues. Includes performance tuning guidance and discusses when PostgreSQL might not be the right choice.

Just Use Postgres!

This is something I have been saying for some time already. Why spread your data across multiple platforms? Some say security. I personally prefer making my platform redundant and hardened. If something goes wrong it’s easier to find the problem and fix it, everything is in one place.

i used a lot of different databases, Postgresql is the most complete one but not a golden hammer, i have an app where i use PocketBase and that’s perfect choice for the requirements of the project.
Use the database that is good enough to run your project without hiccups, don’t use tank to kill a fly.
and MOST important advice - don’t optimize for scaling early

Postgres is not good enough for development.

So recently been using mongo, and this seems so weird and lots of issue are just because a new field was introduced later without proper migrations and data seeding. I know its the fault of developers, but it would be pretty hard for them to mess this much in the postgres environment.

Postgres is incredible for the core data layer, but what’s often overlooked is the operational side. A performant Postgres setup requires understanding EXPLAIN plans, query optimization, connection pooling, vacuum tuning - it’s a whole skill tree.
Once you’re running Postgres at scale, the next challenge is monitoring and incident response. A slow query at 2am doesn’t announce itself gently. You need real-time query performance tracking, automatic detection of cascade failures (lock storms, connection pool exhaustion), and rapid remediation.
Most teams discover their Postgres blind spots during incidents. That’s where tools like HealOps shine - they automatically correlate slow queries with system changes, identify which connections are deadlocking, and surface the context you need to fix it quickly rather than spending 30 minutes digging through logs.