Give your team self-serve data access without compromising security. CodeToQuery converts plain English questions into safe, parameterized SQL queries with built-in guardrails for Ruby on Rails applications.
# Ask a question in plain English
query = CodeToQuery.ask(
prompt: "Show me top customers by revenue this month",
allow_tables: %w[customers orders],
current_user: current_user
)
# Check if it's safe to run
if query.safe?
results = query.run
puts "Found #{results.rows.length} results"
end
# Or inspect the generated SQL
puts query.sql #=> SELECT customers.* FROM customers...
puts query.params #=> { start_date: "2024-01-01", ... }
Everything you need to enable self-serve data access while maintaining security and performance.
Works with OpenAI or local models to understand natural language questions and convert them to SQL.
SQL linting, table allowlists, EXPLAIN plan checks, and readonly execution keep your data secure.
Understands your Rails models, associations, and scopes to generate accurate, context-aware queries.
Automatically injects tenant filters and access rules based on your application's security policies.
Add the library to your app and provide a DB schema snapshot.
Send a natural‑language request like 'top 10 invoices by amount this month'.
Receive proposed SQL + parameters, optionally show a diff/approval UI.
Execute against read replicas or behind a guard—return results to users.
gem 'code_to_query'
rails code_to_query:bootstrap
to generate your schema context.
CodeToQuery.ask
with your natural language prompt.
CodeToQuery.configure do |config|
config.openai_api_key = ENV['OPENAI_API_KEY']
config.openai_model = 'gpt-4'
# Security settings
config.enable_explain_gate = true
config.allow_seq_scans = false
config.max_query_cost = 10000
config.require_limit_by_default = true
end
No—by default it returns SQL + parameters. You decide when/where to execute (and can require approval).
Use read‑only roles and allow‑lists to keep generated SQL scoped to SELECTs unless you explicitly allow writes.
PostgreSQL first; MySQL and SQLite are on the roadmap. Since it outputs SQL, it can work wherever your adapter does.
No. Provide a schema snapshot so models can reason without touching PII.