Elasticsearch, PostgreSQL, and the ACID Test

When developers talk about databases, one acronym comes up again and again: ACID. Atomicity, consistency, isolation, and durability are the safety guarantees that define what it means to be a transactional system. If your database is the source of truth, these guarantees keep your data safe.

Search engines were built with a different goal. Systems like Elasticsearch prioritize distributed indexing and scale. Transactional guarantees were never part of the design. By contrast, relational databases like PostgreSQL were born in the transactional era, with ACID at their core from the beginning.

Many Postgres users already combine these two worlds by treating their favorite database as a search engine, leaning on built-in full-text search or extensions like pg_search (providing bm25 relevance scoring). By doing this, they get something Elasticsearch cannot offer: an ACID-compliant search engine. Or, as we like to call it, a search database.

But to understand why ACID matters in this context, and why it draws such a sharp line between databases and search engines, we need to revisit what the acronym actually means.

What is ACID?

The idea of transactions dates back to IBM’s System R in the 1970s, the project that also gave us SQL. The key insight was that developers shouldn’t have to reason about half-completed operations: a bundle of reads and writes should either all succeed, or none do. This model made it possible to build reliable applications on top of unreliable hardware.

A decade later, Theo Härder and Andreas Reuter coined the acronym ACID to describe the four essential properties of these transactions:

• Atomicity means all-or-nothing. If one part of an action fails, the whole transaction is rolled back.
• Consistency means that transactions preserve invariants. If the database starts valid, it ends valid. It’s worth two things. Firstly, consistency is the most overloaded term: this isn’t the same as distributed / eventual consistency or CAP theorem consistency. Secondly, it's up for debate is this is something applications or databases should be responsible for (although it's nice when databases can help).
• Isolation means concurrent transactions don’t interfere with each other; the outcome is as if they ran one after another.
• Durability means that once a transaction or action commits, its changes survive crashes or power loss.

For many developers today, the clearest introduction to these ideas comes from Martin Kleppmann’s Designing Data-Intensive Applications.

Kleppmann notes that ACID has become slippery over time. Different systems interpret isolation differently, vendors sometimes use “ACID compliant” as a pure marketing slogan, and often consistency feels like an application goal instead of a database one. Still, the four letters remain a useful guide when comparing systems with different design goals.

Why We Think Search Needs Transactions

At first glance, it might seem odd to even suggest a relationship between ACID and search systems. Isn’t search about relevance and ranking? In practice, search is almost always tied to the mutable, relational data it’s sourced from. The difference between a search database and a search engine is the amount of trust you can put in these two worlds being in sync.

This matters where the searcher is motivated by precision. Financial records and legal documents are constantly changing; and when a search is executed the result should reflect now, not some stage in the past. Imagine searching for a record that was just deleted. In Elasticsearch it may still show up, even though the source of truth has moved on. In Postgres, that would be impossible. These results can be driving important business decisions.

Modern Treasury, one of ParadeDB's early design partners sums it up well:

Read-after-write consistency is fundamental to payments. It ensures transactions are visible the instant they’re persisted, which is critical for reconciliation, ledger accuracy and trust in our services.

This is what ACID brings to search: trust. You can rely on your search results to reflect the system of record in real time, without dangling references or stale indexes. As a side-effect it also reduces technology sprawl, removes sync jobs, and eliminates reconciliation logic. A search database is a simpler and safer foundation for user-facing search workloads which prioritize correctness.

ACID in Elasticsearch

Elasticsearch was never a database; it was built as a distributed search engine first, not as a transactional system of record.

Atomicity in Elasticsearch stops at the document boundary. Indexing or updating a single document is atomic (with no option to group writes), but multi-document operations like the bulk API aren’t transactional. If operation five fails, operations one through four are already committed and cannot be rolled back.

Consistency is enforced only at the field level. A numeric field won’t accept text, but Elasticsearch won’t prevent you from inserting an order pointing to a non-existent customer. Invariants like foreign keys or uniqueness constraints must be enforced in application code, with all the complexity that entails.

Isolation is absent. Elasticsearch has no concept of multi-statement transactions, so traditional isolation levels don’t exist. Each indexing or update request is applied independently, and concurrent operations can interleave without guarantees about ordering or serializability.

Durability is the strongest property for Elasticsearch. Every write is appended to the translog on the primary shard and fsynced before acknowledgment. In default mode, the write isn’t confirmed until all in-sync replicas have also persisted it. That ensures crashes don’t lose any acknowledged writes.

It’s also worth noting that Elasticsearch doesn’t provide full read-your-writes for search. A newly indexed document is immediately retrievable by ID, but it won’t appear in search results until a background refresh makes it part of a Lucene segment. Because of the distributed nature of Elastic sharding dirty-reads are also possible under failure. These don’t fall under any of the letters of ACID (although it may be tempting to slip them into C), but are still relevant when we are talking about correctness.

None of these trade-offs are flaws. They’re exactly what make Elasticsearch fast, distributed, and scalable. The pain comes when developers try to treat it as something it isn’t: a system of record.

ACID in PostgreSQL

PostgreSQL, by contrast, was built with transactions at its core. Its entire model assumes ACID from the ground up.

Atomicity spans multiple statements, tables, and rows. If you update ten tables in a transaction and the last one fails, Postgres rolls back the entire unit of work. Developers never have to wonder which changes applied and which didn’t.

Consistency is actively guarded. Postgres enforces foreign keys, uniqueness, and check constraints. It will block an order without a valid customer or a duplicate email address. Instead of pushing invariants into application logic, Postgres makes them first-class.

Isolation is explicit. Postgres exposes three levels (read committed, repeatable read, and serializable) each with well-defined semantics. Behind the scenes, multi-version concurrency control (MVCC) ensures concurrent transactions don’t step on each other’s toes.

Durability is guaranteed by the write-ahead log (WAL). A transaction isn’t acknowledged until its WAL record is safely flushed to disk. If Postgres says the transaction committed, that fact will survive crashes and power failures.

Outside of ACID Postgres also guarantees strict read-your-writes semantics: once you commit a change, your subsequent reads will always reflect it. Because Postgres isn’t a distributed system, there’s no ambiguity: visibility is immediate and consistent.

Postgres’s extensibility means new workloads can live directly alongside its transactional core: from time-series, to geospatial, to vector search. ParadeDB follows in that tradition, bringing full-text search and analytics into the database while keeping ACID guarantees intact.

Summary

Elasticsearch optimizes for scalability. Postgres optimizes for trust. For years, developers stitched them together: Postgres for correctness, Elastic for search, with pipelines in between. That works, but keeping the two systems aligned creates data lag (or even differences), stale indexes, consistency gaps, and operational overhead.

ParadeDB removes that complexity. By extending Postgres with BM25-powered search and a dedicated SQL search API, it becomes something new: a search database. You get the safety of ACID transactions and the power of a search engine (think bm25, tokenization, fuzzy matching, boosting, proximity queries, and faceting) in one system.

And you don’t have to replace what you already run. ParadeDB can serve as your primary database, or as a logical replica that delivers real-time search next to your existing Postgres server.

Ready to try ACID-compliant search? Get started with ParadeDB