Skip to main content

One instance, three databases

control, experiment and kb, reached by three connection strings. That seam is what lets any plane move to its own instance later by changing configuration rather than code. control.customers is the source of truth for tenancy, mirrored into the data databases.

Multi-tenancy

Postgres row-level security on customer_id, an app.current_customer_id session setting, and a non-superuser application role. Not application-layer filtering — a missing WHERE clause cannot leak another tenant’s rows.

Why CNPG, and not a managed Postgres

The knowledge database needs pgvector, Apache AGE and pg_search. No managed Postgres offers all three. That single constraint is why the whole data plane is CloudNativePG rather than a hosted service — it is not a preference.

Blobs

Artifacts and knowledge blobs go to S3-compatible object storage (Cloudflare R2 or AWS S3): one shared bucket with per-tenant prefixes, with the pointer and SHA-256 held in the database. Reference-without-upload is supported, which is what lets an air-gapped customer keep checkpoints in their own bucket while Probe holds only the pointer.

Backups

Continuous WAL archiving to object storage via Barman, giving point-in-time recovery with an RPO of five minutes or better.

The client side

The SDK is the implementation. The CLI, the MCP source adapter, and the passive integrations all use it, which is why the CLI and SDK have capability parity and differ only in ergonomics.

Deployment topologies

Managed

The hosted service at research.prbe.ai. Dashboard, knowledge engine, integrations, everything.

Self-hosted

The same Helm chart on your cluster. Data residency: the software never contacts the vendor.Default is engine-off and dashboard-less; the knowledge engine is a values flip.