Gelida applies the same rigour to protecting your credentials and data that you apply to your Snowflake environment. Here is exactly how.
Snowflake passwords encrypted with AES-256-GCM before being written to the database
Encryption key stored as a server-side environment variable — never logged, never in source code
Credentials decrypted only in-memory at query time, never returned to the browser
If the database were compromised, encrypted credentials are useless without the key
Every database row is scoped to an org_id — enforced at the query level, not just application logic
Supabase Row Level Security (RLS) ensures users can only access their own organisation's data
Cached analytics data stored per-org — one org cannot read another's cache
API routes validate session on every request before touching any data
Gelida connects to Snowflake with a dedicated read-only service user
Queries run only against SNOWFLAKE.ACCOUNT_USAGE and INFORMATION_SCHEMA metadata views
No SELECT on your business databases, schemas, or tables — ever
No INSERT, UPDATE, DELETE, or CREATE operations are possible with Gelida's credentials
All traffic between users and Gelida served over HTTPS/TLS 1.3
Snowflake SDK connections use TLS by default — data in transit is always encrypted
Vercel edge network handles certificate management and renewal automatically
No plain-text credentials or sensitive data in query strings or logs
AI query advisor rate-limited to 20 requests per hour per user
Cache invalidation endpoint rate-limited to 10 requests per hour (admin only)
All errors logged to a dedicated audit table for incident review
Session validation on every API route — unauthenticated requests rejected immediately
Hosted on Vercel — SOC 2 Type II certified, global edge network
Database on Supabase — SOC 2 Type II, ISO 27001, GDPR compliant
No raw Snowflake query data or business data stored by Gelida at any point
Function timeouts enforced at 60 seconds to prevent runaway compute costs
AES-256-GCM credential encryption
Read-only Snowflake access
Org-level row isolation (RLS)
HTTPS/TLS on all traffic
Session auth on every API route
Rate limiting on sensitive endpoints
No raw data stored
Error audit logging
Vercel SOC 2 hosting
Supabase SOC 2 database
Auto-expiring cache (1-12hr)
60s function timeout enforcement
Only aggregated cost metadata — warehouse names, credit totals, query durations, and cost estimates derived from ACCOUNT_USAGE. We never store your actual query results, table data, or any business data.
No. The service user Gelida uses has read-only privileges. It cannot INSERT, UPDATE, DELETE, or CREATE anything in your Snowflake account. It can only read from ACCOUNT_USAGE and INFORMATION_SCHEMA metadata views.
User account data and encrypted Snowflake credentials are stored in Supabase (AWS US East region by default). Cached analytics data is stored in the same Supabase instance and expires automatically between 1 and 12 hours depending on the feature.
Only authenticated members of your organisation. Row Level Security is enforced at the database level — not just in application code. Gelida staff do not access your data except in response to a support request with your explicit permission.
Drop the GELIDA_USER and GELIDA_ROLE in Snowflake at any time. This immediately prevents Gelida from connecting to your account. You can also delete your Gelida account from Settings → Billing, which removes all stored data within 30 days.
If you discover a vulnerability or have a security question, email us directly. We respond within 24 hours.
Contact security team →