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
from gateco_sdk import GatecoClient
client = GatecoClient(api_key="...")
results = client.retrievals.execute(
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.