ACI(D)
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. Durability — the “D” in ACID — means that once a transaction is committed, its changes will survive crashes or failovers. In PostgreSQL, this guarantee is provided by the write-ahead log (WAL), which ensures that all changes are safely recorded before being applied to disk. ParadeDB Community does not write to the WAL, and therefore does not guarantee durability in the face of crashes. For production use cases that require full durability, ParadeDB Enterprise — a closed-source fork of ParadeDB for enterprise customers — includes full WAL integration.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 themax_parallel_worker
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 neither:- It does not support logical replication from a primary Postgres.
- The BM25 index does not get physically replicated and won’t be available on other nodes in a high availability setup.
- 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.