Comparison
Gateco vs pgvector RLS
pgvector Row Level Security is the most common DIY pattern for RAG authorization. We take it seriously — here's when it works and when you outgrow it.
| Capability | Gateco | pgvector RLS |
|---|---|---|
| Deny-by-default (missing metadata = deny) RLS policies pass silently when metadata is missing; Gateco denies | ||
| Audit trail of every retrieval decision pgvector has no authorization-level logging | ||
| Cross-database policy reuse RLS is per-Postgres-instance; Gateco works across 12 DBs | ||
| IDP sync (Azure, AWS, Okta, GCP) | ||
| Principal ABAC conditions from IDP attributes RLS can join other tables but requires careful schema design per tenant | Complex | |
| Instant policy revocation without redeploy RLS changes require schema migrations | ||
| Classification labels + enforcement Classification must be implemented as custom RLS predicates | Manual | |
| EU AI Act audit evidence pack | ||
| Multi-mode search (vector/keyword/hybrid/grep) | Vector only | |
| SSO/SCIM provisioning | ||
| MCP server for AI agents | ||
| Time to implement for 3+ tenants | < 1 day | 2–4 weeks |
Same goal, different scale
Both approaches work for simple cases. The divergence shows at the first edge case.
pgvector RLS (Supabase)
-- Supabase pgvector RLS: department-based access
CREATE POLICY department_access ON embeddings
USING (
department = (
SELECT department FROM users WHERE id = auth.uid()
)
);
-- Works for single-DB same-tenant reads.
-- Breaks when:
-- • users live in Azure AD, not Postgres
-- • department field is in Okta, not a local table
-- • you need ABAC conditions like clearance_level >= 3
-- • you add a second vector DB (Pinecone, Qdrant, etc.)
-- • you need to answer: "who saw what, when?"Gateco
# Gateco: same policy, cross-vendor, with audit trail
import gateco
client = gateco.Client(api_key="...")
results = client.retrieve(
connector_id="my-connector",
query="contractor data access policy",
principal_id="user-123", # resolved from Azure AD via IDP sync
)
# deny-by-default, every decision logged, works on Pinecone tooWhen pgvector RLS is enough
- You use a single Postgres-based vector database (pgvector, Supabase, Neon)
- Your principals and their attributes live in the same Postgres schema
- You have no cross-cloud or multi-DB retrieval requirements
- You have no SSO/SCIM requirements or compliance deliverables
- Your team has strong Postgres expertise and can maintain the schema over time
When you outgrow it
Most ICP-1 teams hit these triggers within 6–12 months of their first RAG deployment:
- You add a second vector DB (Pinecone, Qdrant, Weaviate) — RLS doesn't travel
- Security asks for an audit trail: "who accessed what through the AI last quarter?"
- You need to sync principal attributes from Azure AD or Okta, not a local users table
- EU AI Act or SOC 2 requires documented access control policies, not SQL predicates
- An access rule changes and you need to revoke access instantly, not in a migration window
Migrate from pgvector RLS in a day
Gateco works alongside your existing pgvector setup. Start with a single connector and policy, then expand.