Skip to main content

​
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 in ParadeDB Community 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 ParadeDB 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

By default, ParadeDB favors correctness, even when it comes at the cost of slower query execution. For pdb.agg, transaction visibility filtering is enabled by default. If your workload can tolerate potentially stale aggregate results, you can skip it with visibility => 'raw' to improve performance, or let the query’s size decide with visibility => 'threshold'.

​
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 ParadeDB 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 of ParadeDB indexes, enabling high availability, failover, and read replicas that can serve ParadeDB queries.
If your deployment requires high availability, failover, or read replicas for ParadeDB queries, use ParadeDB Enterprise.

​
Data Integrity

All data inserted into the ParadeDB 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.