You only need postgres

The goal is to make it easier(ish) to build SQL queries without knowing SQL syntax, while still grasping the concepts of select/order/join/etc.

Also to make it faster/less error-prone with drop-downs with only available fields, and inferring the response type.

What do you guys think? Do you understand this example? Do you think it's missing something? I'm not trying to cover every case, but most of them (and I admit it's been ages I've been writing SQL...)

I'd love to get some feedback on this, I'm still in the building process!

Hello folks,

Back in January 2025, I published the early-access version of the "Just Use Postgres" book with the first four chapters and asked for feedback from our Postgres community here on Reddit: Just Use Postgres...The Book : r/PostgreSQL

That earlier conversation was priceless for me and the publisher. It helped us solidify the table of contents, revise several chapters, and even add a brand-new chapter about “Postgres as a message queue.”

Funny thing about that chapter, is that I was skeptical about the message queue use case and originally excluded it from the book. But the Reddit community convinced me to reconsider that decision and I’m grateful for that. I had to dive deeper into this area of Postgres while writing the chapter, and now I can clearly see how and when Postgres can handle those types of workloads too.

Once again, thanks to everyone who took part in the earlier discussion. If you’re interested in reading the final version, you can find it here (the publisher is still offering a 50% Black Friday discount): Just Use Postgres! - Denis Magda

A common scenario in data science is to dump JSON data in ElasticSearch to enable full-text searching/ranking and more. Likewise in Postgres one can use JSONB columns, and pg_search for full-text search, but it's a simpler tool and less feature-rich.

However I was curious to learn how both tools compare (PG vs ES) when it comes to full-text search on dumped JSON data in Elastic and Postgres (using GIN index on tsvector of the JSON data). So I've put together a benchmarking suite with a variety of scales (small, medium, large) and different queries. Full repo and results here: https://github.com/inevolin/Postgres-FTS-TOASTed-vs-ElasticSearch

TL;DR: Postgres and Elastic are both competitive for different query types for small and medium data scales. But in the large scale (+1M rows) Postgres starts losing and struggling. [FYI: 1M rows is still tiny in the real world, but large enough to draw some conclusions from]

Important note: These results differ significantly from my other benchmarking results where small JSONB/TEXT values were used (see https://github.com/inevolin/Postgres-FTS-vs-ElasticSearch). This benchmark is intentionally designed to keep the PostgreSQL JSONB payload large enough to be TOASTed for most rows (out-of-line storage). That means results reflect “search + fetch document metadata from a TOAST-heavy table”, not a pure inverted-index microbenchmark.

A key learning for me was that JSONB fields should ideally remain under 2kB otherwise they get TOASTed with a heavy performance degradation. There's also the case of compression and some other factors at play... Learn more about JSONB limits and TOASTing here https://pganalyze.com/blog/5mins-postgres-jsonb-toast

Enjoy and happy 2026!

Note 1: I am not affiliated with Postgres nor ElasticSearch, this is an independent research. If you found this useful give the repo a star as support, thank you.

Note 2: this is a single-node comparison focused on basic full-text search and read-heavy workloads. It doesn’t cover distributed setups, advanced Elasticsearch features (aggregations, complex analyzers, etc.), relevance tuning, or high-availability testing. It’s meant as a starting point rather than an exhaustive evaluation.

Note 3: Various LLMs were used to generate many parts of the code, validate and analyze results.

For many years MySQL was the default go to open source database, and Postgres was always the “other one,” but at some point in the past 3 years, it flipped.

Now Postgres is considered the default go to for pretty much everything.

Was it when Oracle bought MySQL that everyone bailed?

Always been a huge fan of BSD and Postgres, the engineering on both has always been just really really well done.

I chose PostgreSQL over Apache Kafka for streaming engine at RudderStack and it has scaled pretty well. This was my thought process behind the decision to choose Postgres over Kafka, feel free to pitch in your opinions:

Complex Error Handling Requirements

We needed sophisticated error handling that involved:

• Blocking the queue for any user level failures

• Recording metadata about failures (error codes, retry counts)

• Maintaining event ordering per user

• Updating event states for retries

Kafka's immutable event model made this extremely difficult to implement. We would have needed multiple queues and complex workarounds that still wouldn't fully solve the problem.

Superior Debugging Capabilities

With PostgreSQL, we gained SQL-like query capabilities to inspect queued events, update metadata, and force immediate retries - essential features for debugging and operational visibility that Kafka couldn't provide effectively.

The PostgreSQL solution gave us complete control over event ordering logic and full visibility into our queue state through standard SQL queries, making it a much better fit for our specific requirements as a customer data platform.

Multi-Tenant Scalability

For our hosted, multi-tenant platform, we needed separate queues per destination/customer combination to provide proper Quality of Service guarantees. However, Kafka doesn't scale well with a large number of topics, which would have hindered our customer base growth.

Management and Operational Simplicity

Kafka is complex to deploy and manage, especially with its dependency on Apache Zookeeper (Edit: as pointed out by others, Zookeeper dependency is dropped in the latest Kafka 4.0, still I and many of you who commented so - prefer Postgres operational/management simplicity over Kafka). I didn't want to ship and support a product where we weren't experts in the underlying infrastructure. PostgreSQL on the other hand, everyone was expert in.

Licensing Flexibility

We wanted to release our entire codebase under an open-source license (AGPLv3). Kafka's licensing situation is complicated - the Apache Foundation version uses Apache-2 license, while Confluent's actively managed version uses a non-OSI license. Key features like kSQL aren't available under the Apache License, which would have limited our ability to implement crucial debugging capabilities.

This is a summary of the original detailed post

Having said that, I don't have anything against Kafka, just that Postgres seemed to fit our case, I mentioned the reasoning. This decision worked well for me, but that does not mean I am not open to learn opposing POV. Have you ever needed to make similar decision (choosing a reliable and simpler tech over a popular and specialized one), what was your thought process?

Learning from the practical experiences is as important as learning the theory

Edit 1: Thank you for asking so many great questions. I have started answering them, allow me some time to go through each of them. Special thanks to people who shared their experiences and suggested interesting projects to check out.

Edit 2: Incorporated feedback from the comments

I'm new to Postgres and I'm amazed at the number references I see to psql. I'm coming from SQL Server and we have a command line tool as well, but we've also have a great UI tool for the past 20+ years. I feel like I'm going back to the late 90s with references to the command line.

Is there a reason for using psql so much? Are there still things one can only do in psql and not in a UI?

Edit: Thanks everyone for your responses! My takeaway from this is that psql is not the same as sqlcmd, i.e., not just a command line way to run queries; it has autocomplete and more, Also, since there isn't really a "standard" UI with Postgres, there is no universal way to describe how to do things that go beyond SQL commands. Also, Postgres admins connect to and issue commands on a server much more than SQL Server.

PostgreSQL 18 (now in beta) introduces native functions for generating UUIDv7 — a timestamp-based UUID format that combines the uniqueness guarantees of UUIDs with better sortability and locality.

I blogged about UUIDv7:

• What are UUIDs

• Pros and cons of using UUIDs versions 1-5 for primary keys

• Why UUIDv7 is great (especially with B-tree indexes)

• Usage examples with Postgres 18

Check it out here: https://www.thenile.dev/blog/uuidv7

Curious if others have started experimenting with UUIDv7 and/or Postgres 18 yet.

rainfrog is a lightweight, terminal-based alternative to pgadmin/dbeaver. it features vim-like keybindings for navigation and query editing, shortcuts to preview rows/columns/indexes, and the ability to quickly traverse tables and schemas.

it's also free and open source, you can check out the github below; bug reports and feature requests are welcome!

https://github.com/achristmascarl/rainfrog

We've been thinking a lot about caching this past year.

(1) There's a nice pattern for figuring out opportunities to optimize a Postgres workload, but the downside is that it takes work.

(2) There's lots of generic Postgres-health tooling out there, but we haven't seen any good free & private widgets that answer a question like "would a cache or read replica help this workload?"

So my cofounder made a workload evaluation tool that runs the same logic that our caching proxy (PgCache) uses, but it does so locally (privately) in the browser as WebAssembly.

--

The tool builds on what I think is a good pattern for approaching caching, namely:

1. rank by total time vs what "feels slow."

2. make sure it's actually a caching problem (i.e., rule out writes, or memory issues).

3. check how often a query's tables get written (since that limits the solution set).

4. then you can pick how to optimize your reads.

--

Our tool shortcuts steps 1 and 3, plus the writes check in step 2.

Paste a pg_stat_statements export (or a Postgres log, or a .sql file) and it shows you:

• how your database time splits between reads, writes, and transaction commands, so you know whether caching can help at all

• which read shapes carry that time, counted by statements, calls, or time

• writes by table (this is basically your invalidation map)

The cacheable/not-cacheable piece is specific to our proxy, but the time split, the read shape shortlist, and the write map should help you along your way regardless of what solution you choose.

--

For future iterations we're thinking of including things like time-ordered workload capture, clearer/selectable outputs, refined “hit rate” language, and maybe even an Aurora I/O analysis integration.

here's the link: https://www.pgcache.com/fit

(or here if you'd rather run it yourself: https://github.com/PgCache/pgcache/releases/tag/fit-v0.0.2)

Does it work for you? What could we add to make this more useful?