miniml/.plan/05-database-support.md

A minimal, embeddable semantic data modeling language for generating SQL queries from YAML model definitions. Inspired by LookML.

# 05 — Database Support: What Additional Dialects Buy, and In What Order

## Why this is a strategy question, not a feature question

The Market Cartographer's most damning finding: "MiniML supports exactly two dialects — BigQuery and Snowflake — i.e., **the two platforms that most completely foreclosed the niche natively**" (Semantic Views + Autopilot GA on Snowflake; Conversational Analytics on LookML/BigQuery; both *auto-generate* the models MiniML asks humans to write). The Contrarian could not break the panel consensus precisely because of this fact (`wave2_contrarian.md`: "I cannot manufacture a demand pocket that survives that").

**Dialect expansion is therefore the one product move that changes the market position**, not just the feature list: it moves MiniML from "worse free version of what your warehouse already includes" to "the semantic layer for databases that *have no native semantic layer*" — which happens to be where the ICP (TypeScript app builders) actually keeps its data.

## The engineering precondition

`dialect.ts` is an `if (dialect==="bigquery")… else if ("snowflake")… else throw` ladder in every function; "the marginal dialect in their architecture is a rewrite; in ours it's config" (`wave1_rival.md`). TASKS.md already lists the refactor (one module per dialect). Additionally, each dialect needs its **own validation allowlist and red-team corpus** — `validation.ts`'s function allowlists are dialect-specific, and the security posture (post-fix) is the flagship claim. Budget per new dialect *after* the refactor: **~30–40 hours** (dialect module + function allowlist + corpus + test models + docs), not a weekend.

**Timing: none of this happens in Phase 0/1.** The VERDICT's scope cut is explicit: "do NOT add a third dialect… None of that moves the crux." The refactor + first new dialect is the *first Phase 2 workstream* (months 4–5), gated on the day-90 criteria like everything else.

## Ranked assessment

### 1. PostgreSQL — critical; the expansion bet the whole Phase 2 rests on

- **ICP alignment is total.** The conversion target is a TypeScript engineer at a SaaS company (`02-audience-and-icp.md`). That population's data lives overwhelmingly in Postgres — Supabase, Neon, RDS, Cloud SQL. It is the default database of the exact ecosystem (Node/TS agent builders) whose "seat is still effectively open" (`wave1_market_cartographer.md`).
- **No hyperscaler forecloses it.** There is no "Postgres Cortex Analyst." The native-vendor problem that kills the BigQuery/Snowflake positioning simply doesn't exist here.
- **Competitive cell:** BSL covers Postgres via Ibis — in Python. Zenlytic's metrics_layer covers it — in Python. In TypeScript: nothing library-shaped. This makes Claim 2 in `03-positioning.md` dramatically stronger.
- **Distribution unlock:** the Supabase and Neon ecosystems are large, content-hungry, and amplify community tools; "chat with your Supabase data via Claude, safely" is a template + video + launch post that none of the current dialects can produce.
- **Verdict: ship it months 4–5 of Phase 2, and treat it as a second launch** (new Show HN-worthy moment: "MiniML now speaks Postgres — a governed SQL vocabulary for your agent, no server required").

### 2. DuckDB — high value per hour; the content/demo engine

- Makes every tutorial and demo zero-setup (no warehouse account needed to follow along) — directly serves the YouTube plan and a future in-browser playground.
- The lightweight-data-tooling audience (Ju's newsletter "covers lightweight/DuckDB-adjacent tooling" — `wave1_community_architect.md` #6; MotherDuck's content orbit) is the most receptive amplification audience MiniML has.
- Dialect distance from Postgres is small; do it immediately after Postgres (~15–20 hrs incremental). **Month 6.**

### 3. MySQL/MariaDB — medium; volume without pull

Huge install base among app builders, but weak analytics culture and no visible demand signal in any brief. Do it when a real user asks (an inbound issue requesting MySQL is worth more as social proof than the dialect is as a feature). **Backlog, demand-driven.**

### 4. Redshift — low-medium; declining and enterprise-shaped

Postgres-derived (moderate incremental cost) but the Redshift buyer is an AWS enterprise data team — closer to the anti-audience than the ICP, and the platform is losing share to Snowflake/Databricks (both foreclosed) and DuckDB/Postgres (both covered above). **Only if an identifiable org offers to co-develop.**

### 5. MSSQL / T-SQL — skip

Largest dialect divergence (TOP vs LIMIT, date functions, quoting), and the buyer is the security-conscious enterprise explicitly named in the anti-audience ("no CI + provenance + 2FA-attestation signals is itself an adoption blocker for a paranoid org" — `wave1_security_auditor.md`). Cost is highest where fit is lowest.

### 6. Databricks/Spark SQL — skip

Genie + Unity Catalog Metrics is native, GA, open-sourced, and auto-grounding (`wave1_market_cartographer.md`). Adding this dialect re-enters the exact fight the pivot abandons.

## Strategic sequencing summary

| When | Move | Effect on viability |
|---|---|---|
| Phase 1 (now) | Nothing — two dialects, honestly labeled | Keeps the crux test cheap |
| Month 4–5 | `dialect.ts` refactor + **Postgres** + per-dialect validation corpus | Escapes the foreclosed-by-vendors trap; unlocks Supabase/Neon channels; second launch moment |
| Month 6 | **DuckDB** | Zero-setup demos; playground; lightweight-data audience |
| Demand-driven | MySQL, Redshift | Social proof > feature value; require a named requester |
| Never (this plan) | MSSQL, Spark SQL | Anti-audience, foreclosed, highest cost |

One more consideration from the Contrarian's "notation, not product" blind spot (`wave2_contrarian.md`): the **Open Semantic Interchange (OSI) v1.0 spec** now exists (Snowflake, dbt, Salesforce, AtScale consortium — `wave1_ai_futurist.md`). An OSI import/export path is cheaper than any dialect (~work on the YAML layer, not SQL generation) and hedges the format-standardization risk ("a nonstandard format becomes a liability the moment agents expect OSI"). Slot it opportunistically in Phase 2; see `12-non-content-paths.md`.