BM25 reads on streaming replication standbys worked in 0.18.10, blocked in 0.19.5?

[hjaber]

What happens?

After upgrading from pg_search 0.18.10 to 0.19.5 (Community Edition), BM25 queries on streaming replication standbys are now blocked with an Enterprise-only error.

  ERROR:  Serving reads from a standby requires write-ahead log (WAL) integration,
  which is supported on ParadeDB Enterprise, not ParadeDB Community
  DETAIL:  Please contact ParadeDB for access to ParadeDB Enterprise

Behavior

Version	BM25 Reads on Standby
0.18.10	✅ Works
0.19.5	❌ Blocked (Enterprise error)

Setup

• PostgreSQL 17.6
• pg_search 0.19.5 (Community)
• Architecture: 1 primary + 1 geographic read replicas
• Streaming replication (physical, wal_level = replica)
• Resync strategy: Periodic pg_basebackup to refresh BM25 indexes on standbys
• Self-hosted on Ubuntu 24.04

Questions

1. Is blocking standby BM25 reads in 0.19.5 Community intentional?
2. Is there a supported way in Community edition to run periodic pg_basebackup resyncs for read-only replicas with BM25 indexes?

Use Case

My use case involves relatively static data (~15M rows) where:

• Geographic read replicas improve query latency
• Data changes infrequently (weekly updates)
• Periodic pg_basebackup resyncs (weekly) are acceptable for BM25 index freshness
• No auto-failover/HA required (read-only replicas)

This worked perfectly in 0.18.10 but is now blocked in 0.19.5.

To Reproduce

1. Install PostgreSQL 17 + pg_search 0.19.5 (Community)
2. Create a BM25 index on primary
3. Create streaming replica using pg_basebackup -R -S replica_slot
4. Start standby in read-only mode
5. Query BM25 index on standby: SELECT * FROM items WHERE description @@@ 'query'
6. Result: Enterprise error (in 0.19.5) vs. successful query (in 0.18.10)

OS:

Ubuntu 24.04.3 LTS x86_64

ParadeDB Version (e.g. output of SELECT * FROM paradedb.version_info();):

0.19.5 6f487b4 release

Are you using ParadeDB Docker, Helm, or the extension standalone?

ParadeDB pg_search Extension

Full Name:

hjaber

Affiliation:

hobby project

Did you include all relevant data sets for reproducing the issue?

Yes

Did you include the code required to reproduce the issue?

• Yes, I have

Did you include all relevant configurations (e.g., CPU architecture, PostgreSQL version, Linux distribution) to reproduce the issue?

• Yes, I have

[philippemnoel]

Hi @hjaber. The usage of streaming/read replicas has always been enterprise-only, as per: https://docs.paradedb.com/deploy/enterprise. Prior to v0.19.0, it would fail with a cryptic error. We made the error explicit, so that it is less confusing for open source users who were experiencing confusing issues when trying to use it.

It seems like you were doing a one-time loading from a backup, rather than setting up standard streaming replication? Usage of streaming replicas is intended to be enterprise-only, and I don't expect that to change at this time. We did, however, make logical replication available to community as part of 0.19.0 onwards.

[aviallon]

@philippemnoel I have only a single replica (the other one is just for backup), and I am still seeing issues. How do I fix the problem once it is there?

[philippemnoel]

We're going to resolving this issue in #4901. In the meantime, the workaround would be to use a single instance.

[aviallon]

@philippemnoel this is what I did (scaled-down to zero) and the problem still happened. I resolved by doing a REINDEX of all ParadeDB indexes.
(for the record, I had lost the primary replica).

[philippemnoel]

Got it. Yes this situation is what #4901 is designed to solve.

[philippemnoel]

It is merged and will be released in v0.24.0