Questions about Chion, text-to-SQL, and keeping your database safe

Chion is an AI analytics platform for PostgreSQL that turns plain-English questions into verified, read-only SQL with interactive D3 charts. If you have data but no way to ask it questions, Chion is the answer: direct-connect to Postgres, no ETL, no warehouse copy, no pipeline to configure. The exact SQL appears beneath every answer, so every number is auditable.

Chion generates SQL against a semantic layer built from your schema on connect. Schema profiling catalogs every table and column, a contract restricts what the model can reference, two-layer validation blocks writes and enforces LIMIT, and the query runs read-only. The semantic layer is what makes the generator instant and accurate. No blind prompting, no invented columns.

Text-to-SQL converts plain-English questions into executable SQL queries. Chion builds a semantic layer from your schema the moment you connect, so questions and charts are instant from the first prompt. You type "revenue by region last quarter" and the system generates, validates, and runs the SQL against your connected database.

Conversational analytics lets you ask a question in plain English and get a chart with an explanation, then follow up while the system remembers context. Chion is built for business owners and analyst teams who need answers, not dashboards: direct-connect to your Postgres, no dashboard authoring, no analyst ticket. Each answer includes the SQL so every number is auditable.

Chion doesn't generate SQL on the fly. Every answer runs through a pre-designed analytic strategy. A prompt wrapper sends your question to a single LLM call and returns whatever SQL it writes, with no schema awareness and no validation. Chion cuts through the pain points of AI plugins: seven pre-designed discovery strategies, a typed SQL contract derived from your schema, two-layer validation, and read-only execution. The model proposes, the validator decides, the user audits.

Chion renders eight pre-built D3 chart types, not generated on the fly. Single-line, multi-series line, dual-axis line, stacked area, standard bar, grouped bar, stacked bar, and animated bar race. Chart selection is deterministic: the same data shape always produces the same chart type, scored by compatibility against the query result. All support zoom, pan, filtering, and data labels, and every data point traces back to the SQL that produced it.

Yes. Conversation context is a pre-designed strategy. Ask "show revenue by month," then "break that down by region", and Chion carries forward the schema context, query history, chart state, and active filters so each follow-up refines the prior query surgically. Only the changed parts are regenerated; everything else is reused deterministically from the verified previous turn.

Yes, always. The exact SQL query is displayed beneath every chart and answer. This is a core design principle: every number must be traceable to the query that produced it.

Yes. The exact SQL sits under every chart. Copy it and paste into any PostgreSQL client, BI tool, dbt model, or script. It's a standard read-only SELECT generated through a pre-designed analytic strategy, so it runs as-is without rewriting. Built for the handoff between the person asking and the person operationalizing.

Three things. If you have data but no way to ask it questions, Chion is the answer: the semantic layer builds from your schema on connect, so questions and charts are instant from the first prompt. Second, the SQL is always visible, so every number is auditable. Third, you control the infrastructure: Chion runs managed, dedicated GPU, or on-prem with the same read-only guarantees.

Anthropic Claude today, via paid commercial API tiers (provider terms prohibit training on customer inputs). Chion's architecture is model-agnostic: the pre-designed analytic strategies and two-layer validation don't depend on the model, so OpenAI GPT, Google Gemini, Mistral, and on-premise deployment are on the roadmap. Same pipeline, different proposer.

Yes. Managed cloud, dedicated GPU via CoreWeave, or fully on-premise installation. The pre-designed analytic strategies, two-layer SQL validation, and AES-256-GCM credential vault run the same way in every environment. No architectural compromises across deployments: metadata and summaries in, read-only SQL out. Raw rows never cross the boundary.

No. Chion is built for business owners and analyst teams who need answers, not dashboards. Ask in plain English and Chion writes the verified SQL behind it. The SQL is visible if you want to inspect it, but you never need to draft it.

Yes, that is the point. You phrase the question the way you would in Slack ("DAU last 30 days by plan tier") and Chion writes the verified SQL behind it. The query is visible if engineering asks how the number was produced, but you never have to draft it yourself.

Yes. Chion direct-connects to your PostgreSQL database with read-only credentials. The semantic layer is built from your live schema on connect, so the generated SQL references your actual tables and columns, not guesses. Without schema profiling, every query would be a blind prompt.

It can. Chion is built for business owners and analyst teams who need answers in seconds, not dashboards in weeks: direct Postgres connection, plain-English questions, verified SQL and an interactive chart under every answer. For teams that still rely on dashboards, the generated SQL pastes directly into Tableau, Looker, or any PostgreSQL client.

No. Chion doesn't generate SQL on the fly. Every question runs through a pre-designed analytic strategy bound to your real schema. Schema profiling catalogs every table and column before the LLM sees anything. The SQL contract restricts generation to columns that actually exist. Entity resolution uses pgvector embeddings of real column values. This is how Chion cuts through the pain points of AI plugins: no invented columns, no runaway queries.

The generator runs every request through a pre-designed analytic strategy. It never writes SQL blind. Schema profiling catalogs every table, column, and type up front, and the SQL contract restricts the LLM to that allowlist. If the model proposes an unknown column, the contract rejects it before validation. Generated queries reference only columns your database actually has. No hallucinated columns, ever.

About 60 seconds. Paste a read-only Postgres connection string and Chion direct-connects. No ETL, no warehouse copy, no event instrumentation. The semantic layer builds in the background while you ask your first question, so most users have a verified SQL query and a chart on screen within a minute of connecting.

Yes. Multi-turn conversations are native. Ask "revenue by region," then "break that down by month" and the follow-up refines the prior query surgically: only the changed parts are regenerated, everything else reuses the verified previous turn. That's how the pipeline stays fast and deterministic across long conversations without re-computing from scratch.

Yes. Feature adoption is a pre-designed analytic strategy. Questions like "users who used feature X in the last 30 days" route through the semantic layer, which emits the right date filter, COUNT DISTINCT user_id deduplication, and GROUP BY by dimension. The SQL is visible beneath the chart. Every number auditable, every answer deterministic.

Ask Chion in plain English. It's built for business owners and analyst teams who need answers, not dashboards. "Feature adoption rate by plan tier for last month" runs through a pre-designed analytic strategy: the right deduplication (COUNT DISTINCT user_id), the right ratio (users-who-used / total-users), the right date filter, then one of eight pre-built D3 charts. The SQL is visible under the chart, so engineering can verify the logic. You ask the question and get the answer.

Yes. Every chart shows the exact SQL underneath. Copy it, paste it into a dashboard, version it in dbt, drop it in a Slack thread for review. It's a regular read-only Postgres SELECT generated through a pre-designed analytic strategy. Engineering can audit, optimize, or take ownership without rebuilding anything. The model proposed, the validator decided, the PM audited; the handoff is built in.

Activation funnels are a pre-designed analytic strategy, not an ad-hoc prompt. Ask "activation funnel for users who signed up last month, by channel" and Chion emits COUNT FILTER (WHERE step = 'signup') for the top, COUNT FILTER (WHERE step = 'activated') for completion, and a ratio guarded by NULLIF so a zero-signup channel never divides by zero. The result lands as a pre-built stacked bar chart with the activation rate annotated. Deterministic: same schema, same SQL, same chart.

Jonathan Dag founded Chion in 2024. He is a data analyst with a decade of experience at Meta, Twilio, American Express, MasterCard, and Bosch. Chion exists because every analytics tool he used either trusted the LLM blindly or made the user write SQL by hand. The curated-pipeline design (pre-designed analytic strategies, two-layer validation, pre-built D3 charts) is the answer to that gap.

Chion converts plain-English questions into verified read-only SQL and an interactive pre-built D3 chart. It direct-connects to PostgreSQL, builds a semantic layer from your schema on connect, and runs every question through pre-designed analytic strategies. No ad-hoc generation, no ETL, no dashboard building. Built for business owners and analyst teams who need answers, not dashboards.

Chion is built and operated by Dagnostics LLC, a remote-first company based in Broward County, Florida, United States, founded in 2024.

Yes, that's the point. Paste a read-only PostgreSQL connection string and Chion direct-connects, builds the semantic layer from your live schema in the background, and starts answering plain-English questions within about 60 seconds. 7-day trial, no credit card. You see the real pipeline against your real data, not a canned fixture.

Two minutes. The video walks through direct-connect to a PostgreSQL database, automatic semantic-layer build from the live schema, and one plain-English question routed through a pre-designed analytic strategy that returns verified read-only SQL and a pre-built D3 chart. The exact pipeline you get on your own database.

Yes. Chion is read-only by design. Every query is a SELECT, never INSERT, UPDATE, DELETE, or DROP, enforced by the L1 validator in code, not by LLM instruction. Credentials are AES-256-GCM encrypted in a vault and loaded only for the socket handshake. PostgreSQL Row-Level Security is enforced on every query, and the AI model sees only schema metadata and aggregated results, never raw rows. Every access event is audit-logged.

No. The LLM sees only schema metadata and controlled column summaries, never raw rows. Chion's pre-designed analytic strategies use the LLM to propose SQL; your database executes it; results are rendered server-side and discarded when the session ends. The model never touches actual row data. The model proposes, the validator decides, the user audits.

Chion encrypts credentials with AES-256-GCM in a server-side vault. Plaintext is loaded into memory only at the moment of the socket handshake, used once, and immediately destroyed: a Load-Consume-Purge pattern with no application-memory caching. Credentials are never logged, never returned in API responses, and never sent to the LLM.

No. Every query runs through a pre-designed read-only strategy. Chion cannot INSERT, UPDATE, DELETE, or DROP. Three enforcement layers: the read-only database role you provide, the SQL contract that restricts generation, and runtime validation (L1 read-only SELECT check plus L2 mode-based validator) before execution. Any non-SELECT is rejected before reaching your database. Deterministic, fail-closed.

No. Chion runs on Anthropic Claude today via paid commercial API tiers, and those provider terms explicitly prohibit training on customer inputs. The architecture is model-agnostic: OpenAI, Google Gemini, Mistral, and on-premise deployment are on the roadmap under the same commercial terms. Raw row data never reaches any model regardless of provider.

No. Chion will never sell, license, rent, or share your data or metadata with any third party. Revenue comes from the per-team subscription plans. There is no advertising business model, no data brokerage, no secondary monetization.

Only the aggregated results of the SELECT you asked for, hard-capped at 1,000 rows / 12,000 cells by the pre-designed row-budget strategy. Raw row-level data is never sent to LLM providers. The model receives structural metadata and column summaries, proposes SQL, and your database executes it. The validator decides, the user audits.

Only you, under your authenticated session. Every Chion table uses PostgreSQL Row-Level Security: one customer's queries and data cannot be read by another, enforced at the database layer not the application layer. Every access event is logged to a write-only compliance log. Deterministic isolation, fail-closed on any invariant violation.

Not today. Chion is a pre-seed startup and formal third-party audits (SOC 2, ISO 27001, pen test) are not yet scoped. Security controls are implemented in code and documented on the Trust Center: read-only SELECT enforcement, AES-256-GCM credential vault, PostgreSQL Row-Level Security, audit logging, fail-closed on any invariant violation. We publish what's shipped, not what's aspirational.

Chion processes only structural schema metadata and aggregated query results. Personal data leaves your database only when your own question asks for it, under your connected role's permissions. A formal GDPR program (DPA, Article 28 sub-processor disclosures, representative) is not yet scoped; enterprise customers can request a DPA on contact.

Disconnection purges the semantic layer for that source: all profiled metadata, pgvector embeddings, and column samples are deleted. Query results are session-only and discarded when the session ends. Conversation history is deleted on account deletion. No hidden retention, no background copies.

Email contact@chion.ai with a description of the issue, reproduction steps, and any affected endpoints. We respond within one business day. Do not publicly disclose the vulnerability until we have confirmed remediation.

Every query runs through a pre-designed verification strategy: deterministic, not probabilistic. Four phases: schema alignment against the profiled catalog, contract enforcement on columns and joins, an L1 read-only SELECT check, and an L2 lint for LIMIT, SELECT *, and JOIN validity. Invalid queries are rejected before they reach your database: same question, same data, same outcome.

Yes. The model proposes, the validator decides, the user audits. Chion never runs LLM output unchecked. Every query passes two layers: L1 blocks anything that isn't a read-only SELECT, and L2 lints for missing LIMIT, SELECT *, or invalid JOIN conditions. All queries are capped at 1,000 rows / 12,000 cells, and execution runs through a pre-designed analytic strategy, not ad-hoc generation.

Yes. The model proposes, the validator decides, the PM audits. Every generated statement is a read-only SELECT produced through a pre-designed analytic strategy, lint-checked for structural defects, and hard-capped at 1,000 rows / 12,000 cells. PMs can paste the query into a ticket or PR and engineering runs it as-is. No rewrite needed, no surprises.

No, and never, not only in the demo. Every query is read-only SELECT with LIMIT enforced at the SQL contract level. INSERT, UPDATE, DELETE, and DROP are blocked in code by the L1 read-only validator, not by LLM instruction. The model proposes, the validator decides, the user audits. Deterministic, fail-closed.

Yes. Chion is built on Supabase Postgres, Auth, Edge Functions, and Vault. Your database credentials are encrypted in Supabase Vault with AES-256-GCM, loaded only for the socket handshake, and purged immediately. We run the same primitives we recommend to customers, and apply the same dedicated read-only role pattern ourselves for every connection.

$29/mo Starter, $99 Pro, $299 Max, custom Enterprise. Flat per team, not per seat. Every plan starts with a 7-day trial, no credit card required. Starter includes 50 verified questions per month, Pro 250, Max 750, Enterprise unlimited. Each question runs through Chion's pre-designed analytic strategies against your live PostgreSQL schema.

Yes. 7 days, no credit card. Direct-connect your PostgreSQL database, build the semantic layer, and run real questions through the pre-designed analytic strategies before you pay anything. You're testing the actual pipeline against your actual schema, not a canned demo.

Credits are the usage allotment included with your plan. Starter includes 50 per month, Pro 250, Max 750, and Enterprise is custom. Schema questions ("what tables do I have?") stay free on every plan.

Each plan includes a monthly usage allotment. Schema exploration, saved-chart reloads, and validator repair retries do not reduce that allotment. If you need more volume, upgrade your plan or buy a credit pack.

Yes. One click from the billing page. No email, no retention call, no "please don't go" screen. Your plan stays active through the end of the current billing cycle, so you keep the credits you already paid for. After that, you keep access to your question history and generated SQL.

Schema exploration stays free. Ask "what tables do I have?" or "describe this column" at no cost, as always. For more verified questions, three options: wait for the monthly reset (same day each month), buy a credit pack ($25 for 50, $45 for 100; pack credits never expire), or upgrade your plan and the difference prorates to the current cycle immediately.

Not today. Chion bills monthly only. Pricing is already flat per team, not per seat, so a single Pro subscription at $99/mo covers everyone on your workspace. If your team needs custom annual terms, the Enterprise plan is custom-quoted; contact sales.

Anytime. Upgrades are instant: the price difference prorates to the current billing cycle and the new credits are available right away. Downgrades take effect at the end of the current cycle, so you keep the credits you already paid for. No penalties, no ticket, one click from the billing page.

Monthly plan credits don't roll over. They reset on your subscription anniversary day each month (subscribe on the 15th, counter resets on the 15th). Credit packs are different: packs you buy ($25 for 50, $45 for 100) never expire and stack on top of your plan's monthly allotment.

Hourly question caps scale with plan: Starter 3/hr, Pro 10/hr, Max and Enterprise unlimited. These rate limits are a deterministic guardrail that protects platform stability and your database from runaway query loops, alongside the 1,000-row / 12,000-cell budget and read-only SQL enforcement. No surprise overage charges. You see the cap, you stay under it, you pay what's on the plan.

Prorated refunds within 14 days of your first charge, no questions asked. After that window, cancel anytime and keep access through the end of the current billing cycle. You're never charged past what you've used. All payments run through Stripe, and refunds process back to the original payment method.

PostgreSQL today: direct-connect, no ETL, no warehouse copy. Chion works with every major hosted provider: AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL, Neon, and Supabase, plus self-hosted PostgreSQL reachable from Chion's egress. BigQuery, Snowflake, and MySQL are on the roadmap.

Not yet. PostgreSQL is the only direct-connect database today. BigQuery, Snowflake, and MySQL are on the roadmap with no confirmed ship date. In the meantime, warehouse data replicated into Postgres via Fivetran, Airbyte, or a CDC pipeline is queryable through Chion's pre-designed analytic strategies against the Postgres tables.

A dedicated read-only PostgreSQL role with CONNECT, USAGE, and SELECT on the schemas you want analyzed. No write privileges, no superuser, no replication role. Chion's pre-designed analytic strategies only issue SELECTs and the L1 validator enforces that in code. Grant only what you want Chion to see; Row-Level Security policies on your tables are honored on every query.

Yes. If your event data lives in Postgres, Chion direct-connects and queries it. Common patterns are pre-designed analytic strategies: funnel conversion by channel, DAU/WAU/MAU with stickiness, retention cohorts. If your events are in a warehouse like BigQuery or Snowflake, replicate the relevant tables to Postgres today (via Fivetran, Airbyte, or a CDC pipeline); native BigQuery, Snowflake, and MySQL connectors are on the roadmap.

PostgreSQL: every managed provider (RDS, Aurora, Azure Flexible/Single, Cloud SQL, Neon, Supabase) plus self-hosted PostgreSQL. The 2-minute demo video walks through a PostgreSQL 14 fixture database; the same pipeline runs against your own database when you connect.

Most SQL generators write queries on the fly. Chion runs each question through a pre-designed analytic strategy. Chion profiles your live schema first, binds the model to a typed SQL contract, validates the query in two layers, and shows the exact SQL under every chart. If validation fails, a deterministic repair loop (up to 2 attempts) rewrites the query with error context. No hallucinated columns, no runaway queries, no blind prompting.

Dashboards show pre-built views someone else configured. Chion is built for business owners and analyst teams who need answers on the fly: direct-connect to Postgres, no ticket, no analyst, no wait. Each answer includes the SQL so you can verify it.

Chion runs questions through a pre-designed analytic strategy; ChatGPT generates SQL on the fly. ChatGPT writes SQL from a pasted schema but cannot connect to your database, execute the query, validate results, or render a chart. Chion does all four through a curated pipeline: live read-only connection, contract-based validation, chart selection across eight pre-built D3 types, and full audit logging. No hallucinated columns, no runaway queries.

Chion direct-connects to your Postgres; Tableau and Looker require ETL first. No pipeline configuration, no dashboard build. Ask in plain English and get a verified SQL query plus an interactive chart in seconds. Pricing is flat per team, not per seat.

Chion enforces four invariants most SQL chatbots skip. Every question runs through a pre-designed analytic strategy, not ad-hoc LLM generation. All queries are read-only SELECT. Every query passes a two-layer validator before execution. Credentials live in an AES-256-GCM vault, never cached in application memory. The model proposes, the validator decides, the user audits.

Often, yes. Chion direct-connects to your Postgres; Amplitude and Mixpanel require you to instrument and emit events first. For activation, churn, feature adoption, and NPS out of your existing tables, Chion is built for business owners and analyst teams who need answers, not event schemas. Plain-English questions run through a pre-designed analytic strategy, not ad-hoc LLM generation. If you want session replay or experimentation features, Chion sits alongside them and answers the questions your event schema doesn't cover.

PostgreSQL 12 through 17. No server-side extensions required. Standard tables, views, and materialized views are profiled into the semantic layer on connect and queried through pre-designed analytic strategies. PG 12+ also unlocks the CTE inlining optimizer behavior that Chion's WITH-clause strategies rely on.

Yes, multiple layers. Credentials are wrapped in an AES-256-GCM envelope in Supabase Vault, loaded once for the socket handshake, and purged immediately (Load-Consume-Purge). All traffic uses sslmode=require. Every query passes the L1 read-only SELECT validator and the L2 mode-based validator before reaching your database. Deterministic, fail-closed: the model proposes, the validator decides, the user audits.

Yes. Replicas are the natural target. Chion only issues read-only SELECTs through pre-designed analytic strategies, which maps perfectly to a replica endpoint: zero write risk, offloaded compute away from the primary, no impact on transactional workloads. Paste the replica's host into the connection string. The semantic layer builds against the replica's schema identically to the primary.

Yes. Chion direct-connects through PgBouncer in transaction pooling mode. Every query is a short-lived read-only SELECT, so session-state binding isn't an issue. For Supabase, use the transaction pooler at port 6543. For Azure, use the built-in PgBouncer on port 6432. Curated, deterministic execution, not ad-hoc connection churn.

Extension tables and views are queryable like any other relation: the semantic layer profiles them on connect and pre-designed analytic strategies run against them. Extension-specific functions (PostGIS ST_* functions, TimescaleDB time_bucket, pgvector operators) are not in Chion's function allowlist today; the workaround is to wrap them in a materialized view that precomputes the result, and Chion queries the view directly.

No. A plain read-only role with CONNECT, USAGE, and SELECT on the tables you want queried is enough. Chion's pre-designed analytic strategies only issue SELECTs and the L1 validator blocks anything else in code, so elevated privileges would grant capabilities Chion cannot use and would never need.

Chion direct-connects to Amazon RDS (including Aurora PostgreSQL-Compatible), Azure Database for PostgreSQL (Flexible and Single Server), Google Cloud SQL for PostgreSQL, Neon, and Supabase. Self-hosted PostgreSQL reachable from Chion's egress works too. The same pre-designed analytic strategies and two-layer validation run identically across every host. The semantic layer builds from the live schema regardless of provider.

Neither. Chion direct-connects to Postgres with a dedicated read-only role. Create the chion_read role and grant it CONNECT, USAGE, and SELECT. The anon and service_role keys are for Supabase's PostgREST API layer, not database connections, so they're not the right auth path for Chion's pre-designed analytic strategies.

Yes. RLS enforcement is database-layer, not application-layer. Chion connects as the PostgreSQL role you provide, so Supabase Row-Level Security policies apply to every query deterministically. The LLM only ever sees schema metadata and aggregated results (never raw rows), so RLS defines exactly what the pre-designed analytic strategy is allowed to aggregate.

Yes. Chion direct-connects through Supavisor in transaction pooling mode. Use port 6543 with the pooler hostname. Every Chion query is a short-lived read-only SELECT that runs through a pre-designed analytic strategy, so there's no session-state binding for the pooler to break.

Yes. Each Neon branch is a separate endpoint, and Chion direct-connects to whichever branch you pick. Select the branch in Neon's Connect modal, copy the credentials, and Chion builds a fresh semantic layer against that branch's schema. Common pattern: point Chion at a "staging" branch for exploratory analytics, then swap to "main" for production answers; each has its own isolated credentials.

Yes. Chion's short-lived read-only SELECTs through pre-designed analytic strategies fit comfortably inside Neon's free-tier compute and storage limits. Cold-start latency adds 1–3 seconds to the first question after inactivity; subsequent questions return in the normal sub-3-second range. Good fit for exploration and early-stage analytics.

"neondb". Verify in Neon's Connect modal under the database dropdown. Chion parses the connection string on paste and picks up whichever database name you selected, so custom database names work identically. The semantic layer builds from the connected database's schema, not the name.

No. Chion direct-connects to your Cloud SQL public IP with sslmode=require. The Cloud SQL Auth Proxy is optional; Google recommends it for production but direct IP is enough for Chion. Every query still goes through the read-only role, the pre-designed analytic strategy, and two-layer validation; the path to the database doesn't change the enforcement.

Chion connects over the public Internet with TLS. Private-IP-only Cloud SQL instances need a public IP enabled, or a Cloud NAT / VPN peering path that routes Chion's egress to the private address. Add Chion's IP to Authorized Networks under Connections → Networking. The read-only role handles everything else.

Every tier: shared-core, lightweight, standard, and high-memory. Chion issues short-lived read-only SELECTs through pre-designed analytic strategies, so connection count stays low and per-query CPU is light. Even shared-core instances handle Chion's traffic without bumping up against connection or memory limits.

Yes. Chion direct-connects to Azure Flexible Server on port 5432 or through the built-in PgBouncer pooler on port 6432. The semantic layer builds from your live schema on connect; the pre-designed analytic strategy runs every query read-only with TLS 1.2+. Chion also supports the legacy Single Server for the remaining lifetime of that product.

Yes. Use port 6432. Azure Flexible Server ships PgBouncer in transaction pooling mode, which fits Chion perfectly: every query is a short-lived read-only SELECT with no session-state binding for the pooler to break. Direct-connect on 5432 also works if you prefer bypassing the pooler.

Chion connects over the public Internet with TLS 1.2+ and sslmode=require. Azure Flexible Server configured for private access only needs a public endpoint enabled or a VPN peering path that exposes the server to Chion's egress. Every connection still lands a dedicated read-only role on the server side. The same enforcement boundary whether the path is public or peered.

Yes. Aurora PostgreSQL-Compatible uses the same wire protocol as standard RDS PostgreSQL, and Chion direct-connects to either. Point Chion at the reader endpoint for optimal read-only performance: Chion only issues SELECTs through pre-designed analytic strategies, so a reader replica is the natural fit and offloads work from the writer.

Not today. Chion uses standard PostgreSQL password authentication. Credentials are stored in an AES-256-GCM vault on the server, never cached in application memory. Create a dedicated read-only role with a strong password. IAM database authentication for RDS is on the roadmap.

Yes. Chion direct-connects to the RDS primary endpoint. No warehouse copy, no ETL replica. During a Multi-AZ failover, the endpoint DNS updates automatically and Chion reconnects transparently on the next query. The semantic layer stays intact through failover; most answers still return in under 3 seconds once the new standby is promoted.

Yes. Aurora Serverless v2 is wire-compatible with PostgreSQL, and Chion direct-connects to its endpoint. First-query latency after auto-pause is 1–3 seconds while ACUs scale up; subsequent queries hit the normal sub-3-second target. If predictable latency matters more than cost, raise the minimum ACU setting on the cluster so the compute never fully pauses.

Two paths. Move the instance to a public subnet with a security group allow-list for Chion's egress (simplest for trial setups). Or set up VPC peering / AWS PrivateLink from your private subnet to a network Chion can reach (the production pattern). Either way the RDS instance still enforces the dedicated read-only role on the server side, so the enforcement boundary is identical regardless of the network path.

Every PostgreSQL version RDS offers: currently 11 through 16. The pre-designed analytic strategies for window functions, CTE inlining, and PERCENTILE_CONT hit their full accuracy on PG 12+, so PostgreSQL 14+ is the recommended target. Chion direct-connects identically across versions.

Chion authenticates with a dedicated read-only PostgreSQL role and password today; Entra ID (Azure AD) tokens are not a supported auth mode. Credentials live in an AES-256-GCM vault and are loaded for the socket handshake only, never cached in application memory. Grant the chion_read role CONNECT, USAGE, and SELECT; that is the full setup.

Microsoft retired Azure Database for PostgreSQL Single Server in March 2025; migrate to Flexible Server. Chion direct-connects to either one, so the switchover is transparent to Chion: re-paste the Flexible Server connection string and the semantic layer rebuilds against the new host. All pre-designed analytic strategies and two-layer validation work identically on both.

TLS 1.2 or higher with sslmode=require. Azure Flexible Server enforces TLS 1.2+ by default, so Chion's direct-connect handshake succeeds out of the box. No certificate pinning is performed; standard PostgreSQL SSL verification against the system trust store handles server identity.

Chion authenticates with a dedicated read-only PostgreSQL role and password today; Cloud SQL IAM database authentication tokens are not a supported auth mode. Credentials live in an AES-256-GCM vault and are used once per socket handshake, never cached. Grant the chion_read role CONNECT, USAGE, and SELECT; that is the full setup.

Chion connects over the public Internet, so PSC isn't the direct path; PSC expects the caller to originate inside a Google VPC. Two practical options: expose a public endpoint on the instance (simplest for trial use), or run a TCP proxy on a VM reachable from Chion's egress (production-shaped). The read-only role and two-layer validation are enforced identically regardless of path.

Yes. Read replicas are the recommended target for production analytics. Chion only issues read-only SELECTs through a pre-designed analytic strategy, which maps perfectly to a replica: zero write risk, offloaded compute away from the primary, and no impact on transactional workloads. Paste the replica's public IP into the Chion connection string. Same setup as the primary.

PITR is a Neon-side operation; Chion direct-connects to whatever state the branch is in. Before a PITR, Chion queries the current state; after a PITR, refresh the connection so the semantic layer re-profiles against the restored state. Questions then route through the same pre-designed analytic strategies against the restored data.

Yes, and it's the recommended pattern. Branch "staging" off "main" with copy-on-write, direct-connect Chion to staging for exploratory questions, then swap to the main branch for production answers. Each branch has isolated credentials, so business owners and analyst teams can validate new schema or data on staging without any risk to the production semantic layer.

Chion direct-connects to your Postgres database only. Realtime, Edge Functions, and Storage are separate Supabase services with their own APIs; Chion doesn't call them. Anything persisted into your Postgres tables (auth.users, public.* schemas, storage.objects metadata) is queryable through Chion's pre-designed analytic strategies.

Grant SELECT on the auth schema to your chion_read role: GRANT USAGE ON SCHEMA auth TO chion_read; GRANT SELECT ON auth.users TO chion_read. Chion then profiles auth.users into the semantic layer so plain-English questions like "how many users signed up this month?" or "activation rate by signup channel" route through pre-designed analytic strategies. Deterministic SQL, no guessed column names.

Account info, your natural-language questions, the SQL Chion generated, structural schema metadata, and small category-label samples from connected databases (the semantic-layer inputs). Raw rows stay in your database; they never leave. Query results are session-only and discarded when the session ends.

Yes. One-click deletion in Settings removes account info, your question history, generated SQL, schema metadata, and the pgvector embeddings that powered the semantic layer. Two categories are retained by law: billing records (7 years for tax compliance) and email delivery records (24 months, operational). Everything else is user-deletable, no retention trick.

Chion's metadata lives in tenant-isolated Supabase Postgres (US) with Row-Level Security enforcing cross-tenant isolation. Your database credentials are encrypted at rest with AES-256-GCM in Supabase Vault and loaded into memory only for the socket handshake (Load-Consume-Purge). Raw rows from your database stay in your database; they are never copied or persisted by Chion.

Encrypted at rest with AES-256-GCM per the Terms. Credentials are decrypted in memory only during active pipeline operations with TTL expiration: the Load-Consume-Purge pattern. Plaintext is never logged, never written to disk, and never returned in API responses. (§3.3, §8.1)

Your account transitions to read-only at the end of the current billing period; you keep access to your question history and generated SQL through that cycle. Stored data (question history, schema metadata, semantic-layer embeddings) is deleted within 30 days of termination, or sooner on request. Billing records are retained for 7 years per tax requirements. (§4.7, §15.3)

No. Chion does not support HIPAA-covered workloads. Do not connect databases containing protected health information (PHI). Processing PHI through the Service requires a separately executed Business Associate Agreement, which Chion does not offer today. (§6.10)

1,000 rows / 12,000 cells. The pre-designed row-budget strategy is a hard cap on every query. If the result would exceed the cap, the pipeline first coarsens time grain (daily → weekly → monthly), then applies TopK ranking. It never auto-filters date ranges. Silently dropping dates would change the answer. Deterministic guardrails, no runaway queries, no unreadable dumps.

Chion runs complex queries through pre-designed analytic strategies, not one-shot generation. Schema profiling catalogs every table, column, data type, and foreign-key relationship up front. The contract enforces valid JOIN conditions and CTE structure. If the generated SQL violates the contract, a deterministic repair loop (up to 2 attempts) rewrites it with error context. The model proposes, the validator decides, the user audits. Accuracy scales with schema coverage: more metadata, sharper SQL.

Yes. Window functions are a pre-designed analytic strategy, not ad-hoc generation. ROW_NUMBER, RANK, LAG, LEAD, PERCENTILE_CONT, and aggregate OVER clauses are emitted natively when your question implies rankings, running averages, or period-over-period comparisons. The semantic layer picks the right PARTITION BY from categorical columns surfaced during schema profiling. The model proposes, the validator decides, the user audits.

Yes. Each window-function shape is a pre-designed analytic strategy. A ranking question emits ROW_NUMBER or RANK, a running total emits aggregate OVER(), a period-over-period delta emits LAG or LEAD. PARTITION BY is chosen deterministically from the categorical columns cataloged during schema profiling. No ad-hoc generation, same input same output.

Yes. JOIN generation is a pre-designed analytic strategy bound to your real schema. During schema profiling, Chion catalogs every foreign key, column type, and relationship. The SQL contract validates JOIN conditions against those actual relationships before execution, so joins reference real keys, never hallucinated columns. The model proposes, the validator decides, the user audits.

Yes. CTEs are a pre-designed analytic strategy for multi-step queries. Chion emits WITH clauses for cohort analysis, ranked subsets, running totals, and recursive hierarchy traversals, then the validator enforces recursion depth limits and read-only execution. Every CTE is bound to the SQL contract derived from your live schema. No out-of-contract columns, no runaway recursion.

Yes. Multi-table JOINs are a pre-designed analytic strategy. The semantic layer maps your plain-English intent against the profiled foreign-key graph and picks the correct JOIN type (INNER, LEFT, FULL) with validated ON conditions. Questions that span three or more tables route through the same strategy. No ad-hoc generation, no hallucinated relationships.

Chion doesn't propose JOINs on the fly. The schema contract validates every condition against the cataloged foreign keys and column types first. Mis-aliased columns, wrong types, and non-existent keys are rejected before the query reaches your database. If validation fails, a deterministic repair loop (up to 2 attempts) rewrites the JOIN with error context. No runaway queries, no invented relationships.

Yes. Self-joins are a pre-designed analytic strategy for intra-table comparison. When your question implies comparing rows within the same table ("customers who bought in both Q1 and Q2", "users active on consecutive days"), the semantic layer emits a self-join with disambiguated aliases and validated ON conditions. Same question, same aliases, same SQL.

The pre-designed row-budget strategy kicks in. Every query is hard-capped at 1,000 rows / 12,000 cells after JOINs. If the result would exceed the cap, the pipeline first coarsens time grain (daily → weekly → monthly) then applies TopK ranking, never silently dropping date ranges, never truncating randomly. Deterministic guardrails, no runaway queries.

Yes. Negative-phrasing questions route through a pre-designed LEFT-JOIN-IS-NULL strategy. "Products not ordered in 90 days", "customers without a purchase", "features with no adopters" all emit LEFT JOIN with IS NULL filtering on the foreign-key column. The semantic layer detects the exclusion intent from phrases like "without", "no", "not", "missing" and picks the anti-join pattern deterministically.

The semantic layer picks the JOIN type deterministically from your intent. INNER JOIN when the question requires rows in both tables ("orders with their customer name"). LEFT JOIN when you want every row from the primary table even with missing related rows ("all customers and their orders, including customers with none"). Negative phrasing ("without", "no", "missing") triggers a LEFT JOIN with IS NULL. Same question, same JOIN type, every time.

Every JOIN runs through a pre-designed analytic strategy. Chion only joins tables the question requires, never speculative joins. The SQL contract enforces a 1,000-row / 12,000-cell budget measured after JOINs. If cardinality would explode, the pipeline coarsens time grain (daily → weekly → monthly) or applies TopK ranking before truncation. The PostgreSQL planner picks join order against assumed foreign-key indexes; most answers still return in under 3 seconds.

Chion writes JOINs in a logical order that matches your question (primary entity first, then related tables outward). That's the deterministic output of the pre-designed analytic strategy. The PostgreSQL planner then reorders them at execution time using cost-based optimization against live statistics. The generated SQL is visible beneath every chart; run EXPLAIN on it to see the planner's chosen order. Chion never overrides the planner with hints; the planner knows more about your data than any static instruction could.

Yes. Aggregate filtering is a pre-designed analytic strategy. When your question implies a filter on an aggregated result ("regions with revenue over $1M", "cohorts with churn above 5%"), the semantic layer emits GROUP BY with HAVING. The contract enforces type-correct aggregations and the validator rejects filters on non-aggregated columns. Deterministic every time.

Yes. Percentile math is a pre-designed analytic strategy. "Median" emits PERCENTILE_CONT(0.5) WITHIN GROUP, "p95" emits PERCENTILE_CONT(0.95), and "most common value" emits PERCENTILE_DISC. The semantic layer picks the continuous vs discrete variant from the column's classification during schema profiling. Deterministic, same column type, same function.

The semantic layer classifies every column during schema profiling and routes to a pre-designed aggregation strategy. Quantitative columns get SUM or AVG depending on intent. Categorical columns get COUNT or COUNT(DISTINCT). The contract rejects mismatched aggregations before execution. Deterministic, same question, same choice.

The semantic layer marks each column as additive (revenue, cost), non-additive (rate, ratio, balance), or categorical during schema profiling. The pre-designed aggregation strategy maps those labels to SUM, AVG, or COUNT(DISTINCT); the choice is deterministic and visible in the generated SQL beneath every chart. The model proposes, the validator decides, the analyst audits.

The pre-designed row-budget strategy kicks in deterministically. First it coarsens time grain (daily → weekly → monthly) to collapse groups without losing coverage. If that still exceeds the 1,000-row / 12,000-cell cap, TopK ranking surfaces the highest-signal groups. It never auto-filters date ranges. Silently dropping dates would change the answer, and every coarsening is disclosed in the generated SQL so the user can audit what changed.

The semantic layer picks deterministically from the column's role. COUNT(*) counts every row including NULLs, used for "how many orders." COUNT(column) skips NULLs, used when the column itself is the qualifying signal ("how many orders had a discount applied"). COUNT(DISTINCT column) is used for unique-value questions ("how many unique customers"). Same question, same COUNT variant, every time.

The semantic layer picks based on what the filter targets. WHERE filters rows before aggregation: date ranges, region filters, status conditions on raw columns. HAVING filters groups after aggregation: "regions with revenue over $1M" becomes HAVING SUM(revenue) > 1000000. If the filter references an aggregate expression, it's HAVING; if it references a base column, it's WHERE. Deterministic, rule-driven, auditable in the generated SQL.

Percentiles are a pre-designed analytic strategy. For continuous distributions, Chion emits PostgreSQL's PERCENTILE_CONT(fraction) WITHIN GROUP (ORDER BY column): median (0.5), p95 (0.95), p99 (0.99). For discrete distributions where an actual existing value is required, PERCENTILE_DISC is emitted instead. The semantic layer picks the variant based on the column's continuous-versus-discrete classification from schema profiling. Deterministic: same column type, same function.

Yes. The semantic layer recognizes multi-step intent and routes it through a pre-designed CTE strategy. Questions that need intermediate result sets (cohort analysis, ranked subsets, running totals, recursive hierarchy traversals) land as WITH clauses bound to your schema contract. You never write the CTE; Chion generates, validates, and runs it read-only.

Yes. WITH RECURSIVE is a pre-designed analytic strategy for hierarchy traversal (org charts, category trees, reporting chains). The validator enforces an explicit recursion depth limit and the 1,000-row / 12,000-cell row budget caps output. No runaway queries, no infinite recursion, even against malformed hierarchies with cycles.

CTEs keep every step of a pre-designed analytic strategy visible in the SQL beneath each chart. Named WITH clauses are easier to audit than nested subqueries: an analyst or engineer can read the pipeline top-to-bottom, inspect intermediate result sets, and hand off a section without unwinding brackets.

PostgreSQL 12+ inlines non-recursive CTEs by default: results are not cached, they're folded into the outer query. Chion emits standard WITH syntax and lets the planner optimize execution. If you need materialization for repeated reference, copy the generated SQL and add AS MATERIALIZED manually; the pre-designed strategy keeps the baseline SQL portable.

Not in modern PostgreSQL. In PG 12+ the planner inlines non-recursive CTEs by default, so performance is equivalent to subqueries. In PG 11 and earlier, CTEs were materialized as optimization fences: slower for filter pushdown but faster for repeated reuse. Chion emits standard WITH syntax through its pre-designed CTE strategy and lets the planner decide inline-versus-materialize.

Two deterministic guardrails. The validator requires an explicit depth predicate (typically WHERE depth < 10) on every recursive CTE before execution. If the recursive term is missing one, the query is rejected before reaching your database. The 1,000-row / 12,000-cell row budget provides a second hard ceiling. The model proposes, the validator decides. No runaway recursion, even against cyclic hierarchies.

Yes. PostgreSQL 12+ supports WITH ... AS MATERIALIZED to force materialization and AS NOT MATERIALIZED to force inlining. Chion's pre-designed CTE strategy emits plain WITH by default and lets the planner choose. If you copy the SQL into a client and need caching on a repeated-reference CTE, add the MATERIALIZED hint manually; the baseline SQL stays portable.

Yes. The semantic layer maps plain-English intent to a pre-designed window-function strategy. Questions about rankings translate to ROW_NUMBER or RANK, running totals to aggregate OVER clauses, period-over-period growth to LAG or LEAD, gap detection to LAG with date arithmetic. PARTITION BY and ORDER BY are chosen deterministically from the profiled schema. Same question, same shape, same SQL.

PARTITION BY is chosen deterministically by the semantic layer. When your question implies per-group ranking ("top product per customer", "latest order per account"), Chion picks the partition column from the categorical columns cataloged during schema profiling. Same intent, same partition, same SQL. No ad-hoc guessing.

Yes. Rolling windows are a pre-designed analytic strategy. Questions like "running 7-day average" or "trailing 30-day revenue" emit ROWS BETWEEN N PRECEDING AND CURRENT ROW, with the window size mapped from the natural-language phrase deterministically. The semantic layer also picks RANGE BETWEEN when the question implies a time-based window rather than a row-count window.

ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, NTILE, SUM OVER, AVG OVER, COUNT OVER, FIRST_VALUE, LAST_VALUE, and PERCENTILE_CONT WITHIN GROUP. Each maps to a pre-designed analytic strategy (ranking, period-over-period, running totals, percentiles, edge values) picked deterministically by the semantic layer from your natural-language intent.

Temporal direction in the question picks the function deterministically. Backward-looking phrasing ("growth from last month", "change since last reading") emits LAG, which accesses the previous row in the ordered partition. Forward-looking phrasing ("days until renewal", "gap to upcoming order") emits LEAD, which accesses the next row. Default offset is 1 unless the question specifies otherwise, part of the pre-designed period-over-period strategy.

The semantic layer picks based on what the window frame counts. ROWS BETWEEN counts physical rows, used for "running 7-row average" where the unit is the row itself. RANGE BETWEEN counts logical values in the ORDER BY column, used for "running 7-day average" where the unit is calendar days, so a day with zero rows doesn't collapse the window. Rule: index-based window → ROWS, time-based window → RANGE. Same intent, same frame type, every time.

NTILE is a pre-designed distribution-analysis strategy: it divides a sorted partition into n equal buckets. Questions about quartiles, quintiles, deciles, and percentile-rank buckets ("revenue contribution by top 20% of customers" → NTILE(5)) route through it. The semantic layer picks NTILE for distribution analysis, RANK for ordinal ranking, and PERCENT_RANK when you need the actual fraction (0.0–1.0) instead of a bucket index. Same intent, same function.