Skip to main content
TextQL supports three connectivity models. All three share the same security foundations — they differ only in where the infrastructure runs and how your data sources are reached. Regardless of which option you choose, each thread in TextQL is backed by a single-tenant sandcastle — an isolated execution environment that does not persist data and only has access to what you configure.

​
Comparison at a Glance

​
Option 1: Managed Cloud (Standard)

TextQL runs on shared infrastructure in AWS us-west-2, logically separated by organization. Your databases and warehouses are reached over the public internet via a fixed egress IP that you allowlist on your firewall or security groups. Egress IP to allowlist:
All traffic is TLS 1.2+ enforced. Connector credentials (passwords, service account keys, connection strings) are encrypted at rest using AES-256-GCM. Region availability: Standard runs in AWS us-west-2 only. If you have US East or EU data residency requirements, use Option 2 or Option 3. When it fits: Teams that can allowlist a static IP, have no data residency constraints outside us-west-2, and don’t require traffic to stay off the public internet.
Option 1: Managed Cloud diagram
TextQL provisions a dedicated environment (separate compute, separate database) for your organization. Connectivity to your data sources is established via AWS PrivateLink — queries from TextQL’s compute engine to your data sources travel over the AWS backbone and never traverse the public internet.

​
How the connection is established

Because TextQL’s compute initiates connections to your data sources, your team is the service provider and TextQL is the service consumer in PrivateLink terms. You either:
  • Authorize TextQL’s AWS account on your managed warehouse’s PrivateLink connector (Snowflake, Databricks, etc.), or
  • Expose a VPC Endpoint Service in front of a self-managed database.
The self-managed database path requires a one-time step to authorize TextQL’s AWS account as a PrivateLink consumer.
In this model, the static IP allowlist from Option 1 is not required, and no traffic is exposed to the public internet at any hop.

​
VPC peering as an alternative

VPC peering is supported as an alternative for organizations that already operate peered networks at scale. We recommend PrivateLink unless you have an existing peering-based architecture you need to fit into. When it fits: Organizations that require private networking, dedicated infrastructure, and/or have compliance requirements around traffic egress or non-us-west-2 data residency.
Option 2: Single-Tenant + PrivateLink diagram

​
Option 3: Self-Hosted (Within Your Walls)

TextQL is fully deployable on your own infrastructure using Kubernetes (Helm chart), tested and supported on EKS. Your team controls:
  • Where the application runs — your VPC, your data center, or your cloud account
  • How secrets are managed — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or sealed secrets via GitOps
  • Network routing — all outbound connections from TextQL’s compute engine to your databases stay entirely within your network; no traffic leaves your perimeter
When it fits: Organizations with strict data residency requirements, air-gapped environments, or a policy that prohibits third-party cloud access to internal systems. Note that self-hosting requires your team to manage and maintain Kubernetes and carries a higher operational cost than the managed options. See VPC / Self-Hosted Deployments in the FAQ for common setup issues, and the Kubernetes README for full deployment instructions.
Option 3: Self-Hosted diagram

​
Security Baseline Across All Options

For the full security overview, see the Security Whitepaper.