Chapter 20: Good Evening
I am not arriving this time. I have been here — through twenty chapters, through five pillars of search, through materialized views and hybrid pipelines and architecture patterns and migration playbooks and one honest chapter about configuration that I hope you found more useful than uncomfortable.
You arrived with a question. It was, in one form or another, the question every reader brings to this book: can PostgreSQL really do what Elasticsearch does for search?
I have spent twenty chapters answering it. Not with assurances — with SQL. Not with promises — with runnable queries, real extensions, actual materialized views designed for actual use cases. Full-text search with tsvector and GIN indexes. Fuzzy matching that finds what you meant when you did not type what you meant. Phonetic search that knows Smith and Smyth are the same person. Semantic search that understands meaning, not just words. Autocomplete that responds before the thought is finished. Aggregations. Reverse search. Custom analyzers. Relevance tuning. And hybrid search — combining them all through Reciprocal Rank Fusion into something no single technique could achieve alone.
Thirteen methods. Seven languages. Complete parity with Elasticsearch for application search.
The answer is yes. It has been yes since Chapter 4. Everything after that has been showing you how far the yes extends.
This book is the second in a series, and I should like to say a word about the thread that connects them.
Book 1 demonstrated that PostgreSQL could replace Redis for caching. Book 2 demonstrated that PostgreSQL could replace Elasticsearch for search. Different rooms in the same establishment. Different capabilities of the same database. And at the center of both — the materialized view.
In Book 1, the materialized view pre-computes expensive queries so the application never waits. In Book 2, the materialized view assembles searchable data — tsvector columns, embedding vectors, denormalized fields from joined tables — so the search is fast and the source data stays normalized. The same technique. The same instrument. Different music, depending on which room you are in.
I find this deeply satisfying — that one well-understood technique can serve such different purposes with such equal grace. It suggests something about PostgreSQL itself. This is not just a database. It is an ecosystem that most teams use as a database. Each book has been an invitation to explore another room — capabilities that were always there, always available, often overlooked because the default advice pointed elsewhere.
There may be more rooms to show. But that is a conversation for another evening, and this evening is drawing to its close.
I should like to address two readers directly, because I believe they are both in the room.
If you have read this book and decided to keep Elasticsearch — you have not made a mistake. You have made a decision with full information. Twenty chapters of evidence. Honest trade-offs in Chapter 17. Clear boundaries throughout. I have shown you what PostgreSQL can do. I have also shown you what it asks of you. The decision is yours. It is an informed one. And I respect it without reservation.
This book was never about proving Elasticsearch wrong. It was about proving PostgreSQL capable. Those are different things, and the difference matters more than most technical arguments acknowledge.
If you have read this book and decided to migrate — you have a playbook. Chapter 16 provides seven phases, each reversible. Chapter 14 provides architecture patterns for your specific use case. Chapter 15 provides the scaling path. Appendix B provides the checklist you can pin to the wall. The path is documented. Others have walked it. The footing is sound.
And if you have read both books — if you followed me from the cache layer through the search layer, from Redis to Elasticsearch, from “You Don’t Need Redis” to “You Don’t Need Elasticsearch” — then you have more than two books of techniques. You have a philosophy.
The database you are already running can do more than you think. Not everything. Not always. But more than the default advice suggests. More than the tutorials that recommend adding a new service for every new capability. More than the architecture diagrams that treat PostgreSQL as a storage layer and build the intelligence elsewhere.
The intelligence was always in the database. These books have been about helping you find it.
The question you arrived with has been answered. The SQL is shown. The extensions are named. The architectures are blueprinted. The migration is practical. The trade-offs are stated. The automation is available. The household is in order.
It has been my privilege to attend to you.
Good evening.