Build the mental model
A relational database like PostgreSQL organizes data as rows and columns, and each row is precisely identified by a primary key, so exact-match lookups like `WHERE id = 42` are extremely fast through a B-tree index. Elasticsearch instead builds an inverted index for every text field in a document — a pre-built dictionary mapping each word to the list of document IDs that contain it, so finding every document containing "redis" is nearly instant regardless of how many documents exist. That means a relational database excels at structured, exact-match, transactional workloads (payments, inventory counts) but is weaker at free-text search, relevance ranking, and fuzzy matching, while Elasticsearch is strong there but weaker at multi-table joins, strong consistency, and complex transactions. Another consequence of the storage-model difference is that an Elasticsearch update replaces the entire document rather than patching individual columns in place. This extends the mental model you saw in the Redis course, where each piece of data needs an owning system — Redis owns cache and ephemeral data, and Elasticsearch owns the search-optimized read model.
Connect it to a real scenario
Keep the Tutorial Platform's `tutorials` table in PostgreSQL with rows for `id`, `title`, `author_id`, and `created_at` — only PostgreSQL can guarantee referential integrity for enrollment and progress records through foreign key constraints. In Elasticsearch, flatten the tutorial title, lesson body text, and tags into a single denormalized document at index time — you might even duplicate the author's name inside the document to avoid a join at query time. A search for "redis caching" run against PostgreSQL could require a full table scan, but the same search against Elasticsearch's inverted index returns instantly — so route the search box to Elasticsearch while every create, edit, and delete operation still goes straight to PostgreSQL.
Try the working example
PostgreSQL row storage Elasticsearch inverted index
--------------------------------- ---------------------------------
id | title | author_id "redis" -> [doc 12, doc 47, doc 88]
12 | Redis Intro | 7 "cache" -> [doc 12, doc 30]
47 | Redis Cache | 7 "session" -> [doc 12, doc 47]
WHERE id = 12 -> instant (B-tree) match "redis" -> instant (dictionary lookup)
WHERE title LIKE '%cache%' -> scan match "cache" -> instant (dictionary lookup)You can explain the difference between a relational database and Elasticsearch, and decide which owns a given piece of data.5-minute try-it
Classify five kinds of Tutorial Platform data (user accounts, payment records, tutorial body text, tags, enrollment counts) as PostgreSQL, Elasticsearch, or both, and justify each choice.
One important caution
Assuming an Elasticsearch document update is as cheap and partial as a PostgreSQL column update — under the hood it reindexes the whole document, not just the changed field.
Trying to port a relational JOIN pattern (strongly consistent joins across two tables) directly onto Elasticsearch indices — Elasticsearch was not designed for that pattern.
Elasticsearch Guide — Elasticsearch Basic Concepts — Elastic