What’s Next: You Don’t Need MongoDB
I have, throughout this book, confined my remarks to the matter of Elasticsearch. The search cluster. The aggregation engine. The autocomplete service. The percolator. I have demonstrated, in twenty chapters and seven frameworks, that PostgreSQL handles these responsibilities — all thirteen of them — without assistance. I trust the case has been made.
But there is a third service in your infrastructure. One that has been sitting quietly at the far end of the table, confident that its position is secure. After all, it is not a cache. It is not a search engine. It is a database. Surely the Waiter would not suggest that PostgreSQL could replace another database.
I am suggesting exactly that.
MongoDB is, for a certain class of problem, a genuine innovation. Horizontal sharding across hundreds of nodes, schema-free ingestion at planetary scale, a developer experience purpose-built for documents — these are real capabilities, and MongoDB pioneered them. If you operate at that scale, with terabytes of unstructured data distributed across dozens of shards, MongoDB has earned its place in your household.
Most of you do not operate at that scale.
Most of you added MongoDB because your application needed to store semi-structured data — user profiles with variable fields, event payloads, nested objects that didn’t fit neatly into columns — and the relational model felt too rigid. You now run a second database alongside PostgreSQL. You maintain a sync pipeline between them — Kafka, Debezium, or a custom ETL — because your reports need data from both. You back up two databases. You rotate two sets of credentials. You hold two query languages in your head. And you debug consistency gaps at hours that no reasonable person should be awake.
Allow me to introduce the staff you did not know you had.
JSONB provides binary JSON document storage — nested objects, arrays, variable schemas, full CRUD — with GIN indexes, containment queries, path operators, and jsonpath expressions. It has been available since PostgreSQL 9.4, released in December 2014. Twelve years.
GIN indexes on JSONB provide automatic query acceleration. Two operator classes — jsonb_path_ops for containment queries (smaller, faster), jsonb_ops for key-existence checks (broader). Gold Lapel detects your query patterns and creates the right one automatically. You will never call createIndex().
LISTEN/NOTIFY with triggers provides change streams — fire a notification on INSERT, UPDATE, or DELETE, with a JSON event payload, delivered to listening clients in milliseconds. The same mechanism that powered pub/sub in Book 1 now powers document change detection.
Table partitioning, CHECK constraints, and ON CONFLICT provide TTL expiration, schema validation, and atomic upserts — the operational features that make a document store feel complete.
Together:
MongoDB ≈ JSONB + GIN indexes + triggers + LISTEN/NOTIFY
The capabilities have been in your PostgreSQL for over a decade. What was missing was the developer experience — the filter syntax, the aggregation pipeline, the doc_insert and doc_find that make working with documents feel as natural as MongoDB.
Gold Lapel closes that gap. Twenty-one document store methods across seven languages. Fifteen MongoDB-style filter operators — $gt, $in, $regex, $or, $elemMatch, $text. Eight update operators — $set, $inc, $push, $pull. A full aggregation pipeline — $match, $group, $sort, $unwind, $lookup — with the same syntax you already know. Change streams. TTL indexes. Capped collections. All of it, on PostgreSQL.
And here is the detail that connects this to the two books you have now read: your documents live in the same database as your relational data. The same database that serves your materialized views from Book 1 and your search indexes from Book 2. One backup. One connection string. One set of credentials. No sync pipeline. No consistency gap. No second database to deploy, monitor, and debug when it fails at three in the morning.
The benchmarks speak plainly. Gold Lapel serves cached aggregations 85 times faster than MongoDB 7 — 357 microseconds versus 30 milliseconds — because the materialized view, that faithful instrument from Chapter 4 of the first book, has already computed the answer. MongoDB runs the pipeline on every request. The Waiter ran it once.
The next book will cover this in the detail it deserves. The next version of Gold Lapel will continue to automate it.
Three books. Three services. One database.
The Waiter is not yet done. But the table is beginning to look rather well arranged.