I’ve heard versions of that question more than once. It’s the wrong question.
I led DevOps at a niche eDiscovery data warehouse. Engineering proposed replacing our Oracle databases with Elasticsearch to make a new product more profitable. Both products search, so on a slide they looked interchangeable.
They aren’t. A database like Oracle is a system of record. Elasticsearch is a search index. The difference shows up the moment several records have to change together.
In eDiscovery, that happens constantly:
→ A legal hold covers 50,000 documents. If the operation fails halfway, some documents are protected and some aren’t. A database rolls the whole thing back. Elasticsearch leaves you with a partial hold, and in litigation that can turn into a spoliation problem.
→ Production numbering has to be unique and gap-free across a set. That needs transactions. Elasticsearch only guarantees changes one document at a time.
→ A reviewer shouldn’t see a batch of coding decisions while it’s half applied. Databases isolate in-progress work. Elasticsearch doesn’t.
I went to an Elasticsearch conference to test my concerns against practitioners at large companies, and they confirmed them.
None of this makes Elasticsearch a bad product. It’s excellent at what it’s built for: fast full-text search, faceting, analytics. Plenty of serious platforms keep a relational database as the source of truth and feed Elasticsearch from it as a derived index that can always be rebuilt. That pattern works. Replacing the source of truth doesn’t.
Let me be clear: I’m not defending Oracle. In my opinion, they’re the worst vendor in the industry to be in bed with. I avoid them wherever I can and rip out their products wherever I find them. That job never ends, because they keep acquiring more.
But when being in bed with the devil is your critical differentiator, you don’t get to walk out on a whim. You have to understand exactly what that relationship gives you, and what could actually replace it.
So I didn’t just say no. I said that if cost was the real goal, PostgreSQL was a plausible path. But our niche depended on Oracle Text features, like leading-wildcard searches and terms under three characters, that Postgres didn’t match. And I didn’t know how Postgres would perform at 300 TB on our deduplicating storage. If the business was willing to give up those features, we’d need time to build a mock-up and test it before committing.
What I took from it:
- Ask what the data has to guarantee before asking which product stores it.
- “It also does X” is how expensive mistakes start. Compare guarantees, not feature lists.
- When you push back, bring a path you could say yes to, with its real cost attached.
- Hating a vendor isn’t a migration plan. Know what they’re giving you before you try to replace them.
Originally posted on LinkedIn. Join the conversation there.