Answered adoption questions for evaluating BtrQL against existing SQL workflows.
Not directly. dbt covers many more SQL dialects and a broader analytics-engineering workflow. BtrQL is focused on improving SQL as a language: reusable typed abstractions, compiler checks, and generated SQL that still fits normal database workflows.
I got frustrated with tiny SQL mistakes that forced phone-screen merge-request reviews on weekends, and with debugging large SQL snippets by copy-pasting them and unwrapping the query like an onion.
Define types and data-validation rules once, then reuse them across an OLTP backend database, Kafka SQL, and OLAP lakehouse or warehouse work. Moving code to data is a known optimization strategy, but tens of thousands of lines of SQL and stored procedures are hard to read, debug, trace, and review. BtrQL should make that work feel like maintainable source code instead of opaque database text.
BtrQL aims to gradually replace weaker SQL abstractions where it helps, but mixed projects allow existing SQL to stay in place while generated SQL flows through current drivers and migration/review tools.
Yes. BtrQL projects can mix BtrQL and SQL files, so existing SQL can stay in the project while new or repeated query logic moves to BtrQL. Parsed SQL exposes typed objects when supported; otherwise use catalog import from a test database.
The easiest recommended first install is the demo VS Code plugin from the Download page. Choose the package matching your operating system and architecture; macOS and Linux packages are self-contained, while Windows packages require .NET 11. You do not need to download a separate compiler ZIP. Use the CLI tooling guide and dialect compiler downloads when you need command-line compilation, CI checks, or non-editor workflows.
Getting Started publishes btrql compile -d <dialect> -i <file|directory|-> [-t <file|directory>] [--format] and a concrete project-compilation command.
Whoever owned the SQL before should own the BtrQL source and generated SQL. Platform and CI can enforce gates without becoming semantic owners.
BtrQL is build-time only for compiled artifacts; production runs plain generated SQL with no BtrQL runtime.
Published BtrQL syntax should keep working even when newer or better syntax is added later; different syntaxes can coexist. Generated SQL should still be reviewed during upgrades.
BtrQL is not an optimizer, but it makes plan and performance review straightforward because the production artifact is plain SQL.
Explain-plan export or comparison is not a current feature. Review plans with the target database's normal explain, monitoring, and tuning tools against generated SQL.
No. ETL chains and schedulers are out of scope; use orchestration and scheduling tools such as Airflow, dbt, warehouse tooling, migration tooling, cron, or the platform already responsible for those workflows.
Do not use BtrQL as a universal dialect portability layer, ORM/runtime, migration runner, cost-based optimizer, deployment orchestrator, ETL scheduler, or application binding generator. Use dialect-native SQL or catalog import when BtrQL syntax does not cover a construct.
BtrQL projects are single-target; multi-dialect CI requires separate project/config orchestration outside BtrQL.
No. Deployment-user permission validation is out of scope; validate generated SQL or routines under the relevant target role because DBMS grants, roles, definer/invoker rules, column permissions, and row-level security control access.
BtrQL generates SQL for existing database drivers and tools; development tools may execute that SQL for validation or debugging.
Backend bind variables are owned by applications and database drivers. BtrQL parameters are for functions, table-valued functions, stored procedures, and macros; BtrQL is not a bind-parameter runtime.
BtrQL reduces unsafe SQL string-building by compiling structured, type-checked source to SQL, but it is not a parameter-binding runtime. User input must still be bound by the application/database driver, and untrusted source generation remains unsafe.
Out of scope. Result mapping remains the application/data-access layer's responsibility, same as with handwritten SQL; Application integration includes non-normative Java, Python, and TypeScript examples.
No. Java/Kotlin/Go/TypeScript typed binding generation is out of scope; BtrQL emits SQL and project/editor metadata, not application-language models.
BtrQL does not affect isolation levels, transactions, or runtime behavior. Runtime behavior depends on the generated SQL and the tool/session that runs it.
BtrQL may need a DB connection for debug, catalog import, or schema comparison. Use a test/staging/read-only database where possible and manage credentials through normal secret-management and CI controls.
Module-to-file and output-path mapping should be predictable so generated SQL can be reviewed and deployed consistently.
Imported views stay named, not inlined.
Not yet. BtrQL does not currently provide package management for shared modules; teams share modules as source unless a package workflow is added.
val is compile-time only.
DBAs, data engineers, backend engineers, and technical leaders should each have a direct adoption path explaining first workflow, evaluation evidence, and handoff to existing SQL review/deployment processes.
With the volume of code LLMs can now produce, source contributions would be hard to review responsibly. I would rather read feature requests in English, implement changes deliberately, and make sure they are properly tested. Recent attempts to "liberate" open source projects from their creators' influence also make publishing sources unattractive at the moment.
The foundation is free because I want people to try BtrQL without procurement friction. I plan to add paid features later on top of that free base.
Not yet. Locking/concurrency clauses are unsupported in BtrQL syntax; use mixed SQL or catalog-imported database objects when needed. Runtime lock behavior belongs to the database session, transaction, and isolation settings.
Not yet. Generated SQL metadata/audit headers are unsupported; deployment tooling should add trace or audit metadata outside BtrQL. Future BtrQL support should be opt-in, deterministic, and default off.
BtrQL should publish supported DBMS targets by version, coverage, and evidence level; PostgreSQL is the main focus.
Projects support one target dialect; multi-dialect projects are not supported.
Not supported. Remote objects only work when the database exposes them as ordinary importable relation or callable metadata; native synonyms, database links, linked servers, pass-through SQL, and cross-database names need a separate design.
Unsupported constructs are rejected rather than silently rewritten.
For the local demo compiler, processing stays on the user's device or infrastructure and the compiler does not collect telemetry, usage data, schema data, database data, or error reports. Hosted/team evaluation needs separate privacy, DPA, and data-classification terms.
Public supply-chain materials are not ready yet. Buyers should expect an SBOM, signed downloads or checksums, vulnerability reporting, dependency/update policy, and support window before production procurement.