Guarantees

ACID

All reads and writes go through Postgres’ transaction engine. This means that inserts, updates, and deletes to indexed columns are atomic, consistent, and respect Postgres' isolation levels. As of 0.24.0, transactions are also durable, meaning they are write-ahead (WAL) logged and will survive crashes.

Concurrency

ParadeDB is designed to support concurrent reads and writes in the same way that Postgres does — by adhering to Postgres' multi-version concurrency control (MVCC) rules. We maintain an internal testing suite that rigorously measures the read and write throughput of the BM25 index under concurrent load.

Both read and write throughput under concurrent load can be improved by tuning Postgres' settings. For instance, read throughput can be improved by configuring the max_parallel_workers pool and buffer cache size, whereas writes can be improved by increasing per-statement memory.

Correctness vs. Performance

While ParadeDB optimizes heavily around performance, there are some situations where the database can squeeze more performance by relaxing correctness constraints. In these cases, ParadeDB — like Postgres — will guarantee correctness, even if it comes at the cost of slower query execution.

Replication Safety

ParadeDB distinguishes between logical replication and physical replication.

Logical replication refers to replicating changes from a standard Postgres primary (e.g. AWS RDS) into a ParadeDB instance. This is commonly used when ParadeDB acts as a search node built from upstream Postgres changes.

Physical replication refers to running ParadeDB itself in a multi-node, high-availability (HA) setup using write-ahead log (WAL) shipping.

ParadeDB Community supports logical replication, but not physical replication:

• It can act as a logical replica, ingesting changes from a Postgres primary and indexing them transactionally.
• The BM25 index does not get physically replicated and won't be available on other nodes in a high availability setup.

ParadeDB Enterprise supports both:

• It can act as a logical replica, ingesting changes from a Postgres primary and indexing them transactionally.
• It supports physical replication and high availability, ensuring that the BM25 index remains consistent and crash-safe across nodes.

If your deployment requires high availability, or failover, we recommend using ParadeDB Enterprise.

Data Integrity

All data inserted into the BM25 index must conform to the column’s declared type. ParadeDB relies on Postgres’ type system and input/output functions to ensure validity. For example, invalid data will result in a Postgres error at insert time, not at query time.