Fast SQL-only data application builder. Automatically build a UI on top of SQL queries.
2.5k
Stars
175
Forks
140
Open issues
30
Contributors
AI Analysis
SQLPage is a SQL-only web application builder that transforms database queries into interactive UIs without requiring traditional backend code. It's best suited for rapid development of data-centric applications where developers want to work exclusively in SQL, supporting SQLite, PostgreSQL, MySQL, SQL Server, and ODBC-compatible databases. It serves data engineers, business analysts, and developers who prefer SQL-first development over conventional web frameworks.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
SQL-only web app builder: write database queries, get interactive UIs automatically
SQLPage is a Rust-based runtime that transpiles SQL queries into rendered web components (forms, charts, lists, tabs). Users write `.sql` files; SQLPage executes them and outputs HTML/interactive pages. Targets data-centric applications where SQL expertise exists but web development doesn't. Supports SQLite, PostgreSQL, MySQL, SQL Server, and ODBC databases. Adoption appears concentrated among small teams and individual developers building internal tools and dashboards.
Created August 2022, SQLPage emerged as a narrowly-scoped solution to the observation that many data professionals can write SQL but struggle with full-stack web development. It follows a pattern of declarative UI builders (e.g., Streamlit for Python, Retool for drag-and-drop), but specialized for SQL-native workflows.
Repository grew from 0 to ~2,500 stars over 4 years, averaging modest growth (5 stars/week recently). Activity increased measurably in 2023–2024 as Docker support and ODBC integration matured. Growth rate appears plateaued; recent 7-day gain of 5 stars suggests continued but slow adoption rather than viral expansion. No evidence of a single high-profile adoption event driving spike.
Adoption not verified through named deployments, case studies, or reported user counts. README includes Docker hub image and homebrew package, suggesting some production deployment infrastructure exists. Website (sql-page.com) and 'get started' guide imply intended use by non-trivial audience, but concrete evidence of production usage (companies, projects, user testimonials) is absent from README.
Appears to be a single Rust binary that acts as an HTTP server. README shows it accepts `.sql` files from disk, parses them, executes queries against connected databases, and renders results using component templates (list, chart, form, card, tab, text). Likely uses a declarative configuration layer where SQL result columns with specific names (e.g., 'component', 'title') control which UI elements render. Component abstraction suggests separation between query logic and rendering, though source code not inspected.
Not documented in README. No mention of test suite, coverage reports, or testing philosophy.
Last push 2026-06-25 (8 days before evaluation date); active and recent. Repository has been consistently maintained across 4 years with no multi-month gaps evident. Moderate commit velocity inferred from star/fork ratio and update frequency. Not a stagnant project, but growth is incremental rather than accelerating.
ADOPT IF: you have SQL expertise, need rapid internal tool/dashboard prototyping, are willing to accept limited UI customization, and have a supported database. AVOID IF: you require heavily customized UI, complex business logic beyond SQL, real-time reactivity, or need to move fast iterating on UX with designers. MONITOR IF: you're evaluating for a small data team's internal tools but unsure about long-term maintenance; adoption appears real but not yet large enough to guarantee ecosystem maturity.
Independent dimensions
Mainstream potential
3/10
Technical importance
5/10
Adoption evidence
3/10
- Adoption not verified at scale; may be primarily early-adopter and hobby-project usage.
- Limited customization beyond templated components; non-trivial UI requirements force users into custom SQL hacks or back to traditional web development.
- Small maintainer surface area; project appears maintained by small team (inferred from commit history). Bus factor risk if key contributor exits.
- Database support via ODBC introduces operational complexity and potential driver version friction.
- No evidence of enterprise support, SLA, or commercial backing; sustainability depends on continued volunteer maintenance.
Likely to remain a specialized tool for SQL-literate teams building internal data tools. Modest growth expected as self-hosted BI/dashboarding becomes more appealing post-SaaS consolidation, but unlikely to reach mainstream developer adoption. May see increased interest in 2027–2028 if Rust web ecosystem matures further and internal tool markets expand.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- https://sql-page.com
- Language
- Rust
- License
- MIT
- Last updated
- 18h ago
- Created
- 48mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Request parameters fail inside supported nested SQLPage function expressions
Feature Request: Lazy evaluation for sqlpage.fetch_with_meta() to support conditional HTTP requests
Static files served with Last-Modified = now() instead of the file mtime
Refactor app_config.rs: collapse the ~18 default_* functions and group fields, with a doc-coverage test to stop drift
Top contributors
Similar repos
saschagrunert/webapp.rs
A complete full-stack web application written entirely in Rust, featuring a...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
2.5k | +7 | Rust | 8/10 | 18h ago |
|
|
1.7k | — | Rust | 8/10 | 7d ago |
|
|
2.4k | — | JavaScript | 7/10 | 5d ago |
|
|
2.2k | — | Rust | 8/10 | 1d ago |
|
|
1.1k | — | Rust | 7/10 | 4w ago |
|
|
13.6k | — | JavaScript | 8/10 | 4mo ago |
Broader ecosystem (Python + arbitrary libraries vs. SQL-only). Streamlit serves data science and analytics; SQLPage targets SQL-native DevOps/DBA workflows. SQLPage likely faster for schema-to-UI if schema is already in SQL; Streamlit more flexible for custom logic.
Drag-and-drop, visual builders with larger feature surface and SaaS options. SQLPage is code-first and self-hosted only. Retool/Budibase serve wider audience (non-technical); SQLPage assumes SQL literacy.
BI/analytics dashboards with pre-built visualizations. SQLPage is not primarily a BI tool; it's a general-purpose web app builder. Metabase/Superset are more mature for reporting; SQLPage better for CRUD applications.
Library-level SQL query builder for Rust developers. SQLPage is a runtime/server. Different abstraction levels; not direct competitors.
Hand-coded web framework. SQLPage eliminates boilerplate for common patterns (forms, lists, charts). Trades flexibility for speed-to-prototype. Custom code is strictly more powerful; SQLPage faster for data-centric CRUD.





