The error indicates the current role lacks the required privileges to run a ParadeDB function or access a table / index.
ParadeDB inherits PostgreSQL’s role-based security. If your role lacks privileges on a table, function, or extension object, the server blocks the statement and throws “access denied.”
Queries need USAGE on schemas, EXECUTE on functions (e.g., paradedb.search), and SELECT/INSERT/UPDATE/DELETE on tables or indexes involved. Missing any of these yields the error.
Run EXPLAIN
first; ParadeDB shows the objects it will touch.Compare that list with information_schema.role_*
views or \\dp in psql.
Grant only the minimum rights. Example: grant EXECUTE on the paradedb schema’s search function plus SELECT on the target embedding index.
1) Create a role, 2) grant usage on the schema, 3) grant function execute, 4) grant table/index privileges, 5) test the query.
Yes.Wrap the GRANT statements in a migration script and run them whenever you deploy a new ParadeDB index.
• Use separate roles for reads and writes. • Never grant superuser unless required. • Audit \\dp output in CI. • Revoke default PUBLIC rights.
A member inherits privileges from its parent role, but SET ROLE
may be required inside pooled sessions.
.
No. A normal role with USAGE on the paradedb schema + EXECUTE on its functions is enough.
Use SET ROLE
to switch to the target role, then re-run the query. This reproduces the exact permission set.
Create objects through a SECURITY DEFINER migration role and use ALTER DEFAULT PRIVILEGES
so new indexes inherit correct grants automatically.