Enterprise
This page is a practical overview of what exists, what's optional, and what's planned.
What Exists Today
- A single CLI binary (15MB, no runtime dependencies) that analyzes Snowflake, PostgreSQL, BigQuery, Databricks, MySQL, MS SQL, and Redshift SQL.
- 640+ built-in detection rules across security, governance, performance, and correctness.
- YAML policy engine with environment scoping, severity fallbacks, and exception workflows.
- Decision records with SHA-256 integrity verification for audit trails.
- Two deployment modes: CI/CD (gate merges, PR comments) and runtime (gate agent/application SQL execution).
- Rules and policies live in your repo or cloud storage. Outputs go where you direct them.
- Optional catalog integration for schema-aware analysis (Snowflake, PostgreSQL, BigQuery, or Databricks metadata).
Deployment Options
Self-Hosted
You run Lexega in your own infrastructure:
| Component | Location | Control |
|---|---|---|
| CLI binary | Your CI runners | Full |
| Policy files | Your storage (local, S3, GCS, Azure) | Full |
| Decision records | Your storage (local, S3, GCS, Azure) | Full |
Requirements:
- Linux (x86_64, ARM64), macOS, or Windows
- ~15MB disk space for binary
- No runtime dependencies
Optional: Metadata Catalog
If you enable catalog integration, Lexega can connect to your data platform (Snowflake, PostgreSQL, BigQuery, or Databricks) and query metadata to enrich analysis.
If you do not enable it, the core CLI still works fully offline against SQL files.
Licensing
Lexega's commercial packaging is evolving.
What is true today:
- If you have a license key, validation is performed locally by the CLI.
- The CLI can run in restricted networks (including air-gapped environments), as long as you do not enable optional external integrations.
If you're trying to evaluate Lexega for internal use, start with a pilot in one repo.
Support
Support is currently best-effort.
If you're running Lexega in production, treat it like any other new tool: start with a limited rollout, validate outputs in your CI, and keep an internal owner who can adjust policy and workflows.
Portability
Lexega does not require a hosted control plane.
- Policies are files you own and version-control.
- Reports/decisions are artifacts you can store anywhere.
- If you stop using Lexega, you keep all your history and can delete the binary.
Evaluation
If you want to evaluate Lexega inside an organization:
- Pick one repo and run in "report-only" mode first (do not include the --policy CLI argument).
- Store outputs as CI artifacts and review them in PRs.
- Decide whether you want optional integrations (Snowflake catalog, PR comments).
- Expand rollout only after you're happy with signal quality and policy tuning.
Integration
CI/CD
Lexega is a CLI, so it can run in most CI systems. Optional features (like PR comments) are provider-specific.
Policy Management
Store policies centrally if you want:
- Git repository: Version-controlled, PR-reviewed policy changes
- Cloud storage: S3, GCS, or Azure Blob for shared policies
FAQ
Does Lexega need access to my Snowflake account?
It depends.
The core CLI analyzes SQL files statically and does not require a Snowflake connection. If you enable optional catalog integration, Lexega will connect to Snowflake to query metadata.
Can I use Lexega in an air-gapped environment?
Yes. The CLI is fully offline. License validation uses cryptographic signatures, not a license server.
How do I manage policies across multiple repositories?
If you want to centralize policies, you can store them in a shared repo, or in object storage if that matches your environment:
lexega-sql analyze query.sql \
--custom-rules s3://governance/company-rules.yaml \
--policy s3://governance/enforcement-policy.yaml
What happens if Lexega finds a false positive?
Tell us what happened. Contact us at [email protected].
If you want to sanity-check whether Lexega fits your workflow, start with one repo and a single policy file.
Need Help?
Can't find what you're looking for? Check out our GitHub or reach out to support.