SQLPage v0.46.0

This release makes SQLPage applications more reliable across databases, adds new SQL-driven UI components, improves charts and forms, and updates AWS Lambda support.

Highlights

Build richer interfaces

New toast notifications

The new toast component lets you show success messages, warnings, errors, and background status updates without writing custom JavaScript.

Toasts support:

• Plain text or Markdown content
• Icons and colors
• Six screen positions
• Automatic or manual dismissal
• URL-fragment triggers
• Queued notifications that stack automatically

select
    'toast' as component,
    'Saved successfully' as title,
    'Your changes are now live.' as description,
    'check' as icon,
    'green' as color;

Use duration = 0 for persistent messages, or trigger to show a notification after a user clicks a link or button.

New SQL-generated filters

The new facet component makes it easy to add category, status, owner, or tag filters to tables, lists, and cards.

Facets can appear as inline links or as a compact dropdown, with optional “All” links and configurable labels.

select 'facet' as component, 'Status' as description;

select
    'Open' as title,
    '?status=open' as link,
    $status = 'open' as active;

The component creates the navigation; your SQL query remains responsible for applying the selected filter. Because the filters use URLs, users can bookmark and share filtered views.

Richer email messages

sqlpage.send_mail now supports HTML and Markdown email bodies.

set result = sqlpage.send_mail(json_object(
    'to', :email,
    'subject', 'Welcome',
    'body_md', '# Welcome\n\nThanks for **signing up**!'
));

With body_md, SQLPage sends both:

• A plain-text alternative containing the Markdown
• An HTML alternative rendered from the Markdown

You can also provide body_html alongside a plain-text body. body_md and body_html cannot be combined.

More accurate and expressive charts

The chart component gains several improvements.

Add thresholds, targets, and time ranges

Charts can now display reference lines and bands:

select
    80 as yline,
    'Target' as label,
    'orange' as color;

select
    100 as yline,
    120 as yline_end,
    'Warning zone' as label,
    'red' as color;

Use yline for a horizontal reference, xline for an event or date on the x-axis, and yline_end or xline_end to create a band. Reference lines are ordinary query rows, so you can generate as many as needed.

They do not contribute to stacked totals and are not filled as part of an area chart. Their orientation follows the axis, so a yline becomes vertical on a horizontal bar chart.

Color individual data points

Rows can now supply their own color, allowing you to highlight a single bar, slice, point, or range:

select
    label,
    value,
    case
        when value > 90 then 'red'
        else 'green'
    end as color
from metrics;

This works with bar, column, range bar, pie, treemap, scatter, and bubble charts, as well as line and area markers.

Correct alignment for uneven series

Stacked charts now match series by their x-values instead of by point order. Missing values no longer shift later points into the wrong position.

For unstacked line, area, scatter, bubble, and heatmap charts with text categories, series are aligned by label and leave a visible gap where a series has no value.

Other chart fixes include:

• Column charts now render vertical bars correctly.
• Unsupported stacked settings are safely ignored instead of producing an empty chart.
• Tooltip titles inherit the tooltip’s text color.

Better database compatibility

SQLPage no longer unnecessarily casts request variables to text on PostgreSQL, MySQL/MariaDB, SQL Server, and DuckDB.

You can continue writing ordinary SQL:

select *
from users
where id = $id;

The generated SQL is now cleaner—such as WHERE id = $1 instead of WHERE id = CAST($1 AS TEXT)—and the database can infer the appropriate type from context.

This fixes several real-world issues:

• SQL Server comparisons involving non-ASCII nvarchar values
• SQL Server CONTAINS and EXEC statements using variables
• MySQL/MariaDB variables in LIMIT and OFFSET

The explicit cast remains in place for SQLite and ODBC connections where it is needed for predictable comparisons. See the SQL extensions documentation for details.

More predictable forms, APIs, and maps

• Form options_source URLs now retain their existing query parameters when SQLPage adds or updates the dynamic search parameter.
• Searchable single-select fields close their dropdown after an option is chosen.
• sqlpage.request_body and sqlpage.request_body_base64 return NULL when no request body was sent.
• Body-reading failures, including payloads exceeding the configured limit, are now reported as errors instead of being silently treated as empty bodies.
• Invalid map coordinates are logged in the browser console and skipped, so one malformed point no longer breaks the entire map.
• Datagrid rows with icons or images no longer show an unnecessary en-dash placeholder. Explicitly empty descriptions remain empty.

Updated AWS Lambda support

Lambda builds now target the supported Amazon Linux 2023 custom runtime, provided.al2023, instead of Amazon Linux 2.

The deployment archive also includes the sqlpage configuration directory required because Lambda’s filesystem is read-only. Existing deployments should select provided.al2023 when upgrading. See SQLPage’s Lambda instructions and AWS’s OS-only runtime documentation.

Accessibility and developer experience

• Screen readers now announce modal titles instead of reporting an unnamed dialog. See the modal component.
• List-valued configuration options—including OIDC paths and trusted audiences—can now be set through environment variables as space-separated lists. See the configuration reference.
• Documentation for sqlpage.fetch_with_meta now correctly identifies JSON responses under json_body, rather than body.
• Recursive sqlpage.run_sql failures now show one concise, correctly positioned error instead of repeating the entire inclusion chain.
• The bundled Tabler icon sprite is updated from v3.44.0 to v3.46.0, adding 18 icons—including play-bug, remote-control, tabs, vault, and yarn—along with upstream fixes.

SQLPage v0.45.0 (2026-07-21)

• SQLPage can now send emails

  • Configure your outgoing email server information in the SQLPage configuration file, then call sqlpage.send_mail with a JSON message. It returns {"status":"accepted"} on SMTP acceptance. Messages support multiple to and cc recipients, reply-to addresses, and data-URL attachments with a configurable combined decoded-size limit. SMTP passwords are redacted from startup debug logs.

• Release builds are slightly smaller and faster. Unused dependency features have been removed. SQLPage now uses the maintained AWS Lambda HTTP runtime and avoids unused SQLx macros, configuration parsers, multipart derives, CSV serialization support, and build dependencies.

• Configuration loading now includes only the documented JSON, JSON5, TOML, and YAML formats. The config dependency previously enabled its default INI and RON parsers even though SQLPage never documented those formats. Undocumented .ini and .ron configuration files are no longer loaded; migrate them to a supported format before upgrading.

• SQLPage functions can now be composed with database results. Direct calls such as SELECT sqlpage.url_encode(url) FROM links already ran once per row. Per-row evaluation now also works through parentheses, concatenation, COALESCE, JSON constructors, and nested SQLPage functions. The database first decides which rows exist, then SQLPage evaluates the selected expression for each row. This enables patterns that were not previously possible, such as fetching only missing cached values or rendering a reusable SQL file with parameters from each row:

  SELECT
      id,
      COALESCE(cached_response, sqlpage.fetch(api_url)) AS response
  FROM integrations;
  
  SELECT
      'dynamic' AS component,
      sqlpage.run_sql('item.sql', json_object('id', id)) AS properties
  FROM items;

  COALESCE is evaluated from left to right, so the first query only calls the API for rows where cached_response is NULL. If a query returns no rows, none of its selected SQLPage functions run. This also makes database-controlled conditional work possible with scalar SET queries:

  SET refresh_result = (
      SELECT sqlpage.fetch(refresh_url)
      FROM cache_entries
      WHERE cache_key = $key AND expires_at < CURRENT_TIMESTAMP
  );

  Upgrade notes:

  • A sqlpage.* call with only constants or request variables that is the whole value of a selected column now also runs once per returned row. For example, SELECT id, sqlpage.fetch($url) AS body FROM jobs previously made one HTTP request and reused its result; it now makes one request per job. The same applies to side-effecting or expensive functions such as sqlpage.exec, sqlpage.run_sql, and sqlpage.persist_uploaded_file. To run a function once per page, store its result first: SET body = sqlpage.fetch($url);, then select $body.
  • SELECT id, sqlpage.random_string(8) AS token FROM invitations now creates a different token for every invitation instead of repeating one token. If one shared batch token is intended, use SET token = sqlpage.random_string(8); first.
  • A selected function is no longer called when its query returns no rows. Move the call to a separate SET statement if it must run unconditionally.
  • SQLPage-computed values do not exist yet when the database performs DISTINCT, filtering, grouping, or sorting. Queries that use SELECT DISTINCT with a computed projection, reference a computed alias from WHERE, GROUP BY, or ORDER BY, or use ordinal GROUP BY/ORDER BY with a computed projection now return a clear error instead of producing database-dependent results. Apply those operations to the source database columns, or compute the value once with SET when it does not depend on a row.
  • SET x = (SELECT ...) now has explicit scalar-query behavior: zero rows set x to NULL, exactly one output column is required, and multiple columns return a clear SQLPage error. Multiple rows keep the database's scalar-subquery behavior: SQLite uses the first row, while other supported databases return an error. For portable results, make the query intrinsically single-row with a unique predicate or aggregate, or use the database's one-row limiter.

• Access logs now go to stdout. SQLPage now writes the single per-request completion log line to stdout with the target sqlpage::access, matching common application-server and container logging conventions. Diagnostic logs, warnings, and internal errors still go to stderr. If your LOG_LEVEL or RUST_LOG filter is scoped to a specific old target such as sqlpage::webserver::http=info, add sqlpage::access=info so request-completion logs are still emitted. If your log pipeline only collects stderr, update it to collect stdout too.

• OIDC redirects are no longer cacheable. Authorization redirects contain one-time state and post-login redirects set session cookies. SQLPage now sends Cache-Control: no-store for these responses, preventing a browser or intermediary from replaying an expired authorization redirect.

An AI-assisted security audit found three vulnerabilities: one authentication bypass that is high severity for affected OIDC deployments, and two lower-severity issues. It also led to three hardening changes. Upgrade now if you use custom OIDC protected paths.

Security fixes:

• High severity for affected OIDC deployments: protected path bypass.
  • Affected: sites using OIDC with custom oidc_protected_paths, such as ["/admin"], to protect only part of the site.
  • Not affected: sites not using OIDC, or using the default oidc_protected_paths = ["/"] to protect the whole site.
  • Impact: an unauthenticated attacker could use percent-encoded URLs to access pages that should require login. The fix checks decoded request paths against decoded oidc_protected_paths and oidc_public_paths.
• Medium severity: private SQL files could be served after privileged run_sql includes.
  • Affected: apps that call sqlpage.run_sql(...) on private paths such as sqlpage/, dotfiles, absolute paths, or ../ paths.
  • Impact: an attacker who knew the path could request the cached file directly and run it as a public page for a few milliseconds.
• Low severity: debug error messages displayed in production
  • Affected: environment = "production" and pages that can error while serving JSON, NDJSON, SSE, or CSV contents.
  • Impact: an attacker could gather private information about your database schema through error messages.

Additional hardening:

• Safely quote csv and download filename values in Content-Disposition, preventing download filename corruption.
• Reject unsafe OIDC redirect targets containing backslashes or control characters, affecting user-controlled login return targets and sqlpage.oidc_logout_url.
• Bind sqlpage.oidc_logout_url links to the current session, preventing forced logout of another browser.

v0.44.0

This release focuses on making production SQLPage apps easier to understand, debug, and operate. Most apps should keep working without SQL changes, but maintainers should review the notes about logging and uploaded-file permissions.

• Find out why a page is slow. SQLPage can now produce a timeline for every request: when the request arrived, which .sql file ran, how long it waited for a database connection, which SQL queries ran, and how long calls to sqlpage.fetch, sqlpage.run_sql, or sqlpage.exec took. This kind of request timeline is called a trace. SQLPage emits it using OpenTelemetry, the standard format understood by tools such as Grafana, Jaeger, Datadog, Honeycomb, New Relic, and others.
  • Easy start: run the ready-to-use examples/telemetry Docker Compose setup. It starts SQLPage, PostgreSQL, Grafana, Tempo, Loki, Prometheus, and an OpenTelemetry collector, so you can click through a sample app and immediately see request timelines and logs.
  • If you already have a monitoring backend: set OTEL_EXPORTER_OTLP_ENDPOINT and, optionally, OTEL_SERVICE_NAME=sqlpage.
  
• Logging is now structured and safer. LOG_LEVEL is the preferred environment variable for SQLPage log filtering. RUST_LOG still works as an alias, so existing deployments do not need an immediate change. Debug logs for OIDC and sqlpage.fetch no longer dump raw tokens, cookies, claims, or response bodies, while still keeping useful request and response metadata.
• New function: sqlpage.regex_match(pattern, text). It returns regex capture groups as JSON, or NULL when there is no match. This is especially useful in custom 404.sql files for clean dynamic routes such as /categories/sql/post/42 without creating one SQL file per possible URL.
• Uploaded files can now get explicit Unix permissions. sqlpage.persist_uploaded_file(field, folder, allowed_extensions, mode) accepts a fourth mode argument such as '644'. On Unix, uploaded files default to 600, meaning only the SQLPage process owner can read them. If you serve uploaded files directly from nginx, Caddy, or another reverse proxy, pass an appropriate mode such as '644'.
• Charts are easier to tune and more accessible. The chart component now supports show_legend to hide or show the series legend. ApexCharts was updated from 5.3.6 to 5.13.0. It brings fixes for datetime axes, annotations, data labels, legend state, tooltips, keyboard navigation, reduced-motion handling, and built-in palette contrast. SQLPage also fixes the chart toolbar menu in dark mode.
• The SQL parser was updated to sqlparser-rs 0.62.0, which is the latest published version at release time. For SQLPage users, this mainly means fewer false parse errors when using database-specific SQL. Notable additions include more PostgreSQL, MySQL, MSSQL, Snowflake, Redshift, Databricks, Spark SQL, and Teradata syntax, plus a SQLite parser panic fix for incomplete REGEXP/MATCH expressions.
• Card image galleries can avoid layout shifts. The card component now supports top_image_lazy, top_image_width, and top_image_height, so pages with many card images can load more smoothly.
• Datagrid rows can now have stable HTML anchors. The datagrid component supports a row-level id parameter, useful for links, targeted CSS, and small bits of custom JavaScript.
• OIDC login is more robust under repeated unauthenticated requests. SQLPage now caps temporary login-state cookies, avoiding the unbounded cookie growth that could happen when many protected pages were requested before authentication completed.
• HTTP error statuses are more accurate. Malformed multipart form data and invalid UTF-8 text fields now return 400 Bad Request; database connection-pool exhaustion now returns 429 Too Many Requests; invalid non-Unicode static paths now return 400 Bad Request; and paths that accidentally descend into a file now behave like normal missing resources. This should make monitoring dashboards and reverse-proxy logs easier to interpret.
• Invalid response headers no longer crash SQLPage. If a header-only page tries to return an invalid header value, SQLPage now returns a normal error response instead of crashing the request handling path.
• DuckDB :: casts are handled better. SQLPage no longer warns unnecessarily when using DuckDB-style casts.
• Database-backed filesystems fail earlier and more clearly when misconfigured. SQLPage now checks that the sqlpage_files table is available before preparing database filesystem queries, so a missing or inaccessible table produces a direct startup error.
• Dependencies and release tooling were refreshed. This includes updates to Rust, OpenTelemetry, sqlx-oldapi, frontend assets, Docker images, and GitHub Actions used by CI and release builds.

SQLPage v0.43.0 (2026-03-08)

• OIDC protected and public paths now respect the site prefix when it is defined.
• Fix: OIDC provider metadata refreshes now always happen in the background, and with a timeout. Previously, a slow OIDC provider could prevent SQLPage from handling requests for an arbitrary amount of time.
• Fix: forms without submit or reset buttons no longer keep extra bottom spacing.
• add submit and reset form button icons: validate_icon, reset_icon, reset_color
• improve error messages when sqlpage functions are used incorrectly. Include precise file reference and line number
• updated sql parser: https://github.com/apache/datafusion-sqlparser-rs/blob/main/changelog/0.61.0.md
• Add margin bottom in the big number component
• In forms without a submit button (such as auto_submit forms), remove awkward padding at the end of the form

SQLPage v0.42.0 (2025-12-28)

New features

• Better support for alternative databases
  • SQL file parsing
    • add support for some DuckDB-specific syntax (like select {'a': 1, 'b': 2}),
    • same for Oracle-specific syntax
• New docker image variant: lovasoa/sqlpage:latest-duckdb, lovasoa/sqlpage:main-duckdb, lovasoa/sqlpage:v0.42.0-duckdb with preconfigured duckdb odbc drivers. Just run the image and you have a sqlpage connected to a duckdb running. This makes it much easier to use SQLPage on existing local or remote CSV, XLSX, JSON, or Parquet files without any data conversion step.
• New config option: cache_stale_duration_ms to control the duration for which cached sql files are considered fresh.

New Functions

• sqlpage.web_root() returns the web root directory where SQLPage serves .sql files from. This is more reliable than sqlpage.current_working_directory() when you need to reference the location of your SQL files, because it takes into account the --web-root command line argument and the WEB_ROOT environment variable.
• sqlpage.configuration_directory() returns the configuration directory where SQLPage looks for sqlpage.json, templates, and migrations.

Bug fixes

• Fixed oracle-specifc bugs. The entire sqlpage test suite now runs against an oracle database after each change, guaranteeing no regression.
• The default welcome page (index.sql) now correctly displays the web root and configuration directory paths instead of showing the current working directory.
• sqlpage.variables() returned json objects with duplicate keys when post, get and set variables of the same name were present. It now always returns valid json objects without duplicate keys. The semantics of the returned values remains the same (precedence: set > post > get).
• better oidc support. Single-sign-on now works with sites:
  • using a non-default site_prefix
  • hosted behind an ssl-terminating reverse proxy
• Fixed a bug where sqlpage would sometimes redirect to the wrong url after logout, causing logout failures when using sqlpage.oidc_logout_url()

SQLPage v0.41.0 (2025-12-28)

• New Function: sqlpage.oidc_logout_url(redirect_uri) generates a secure logout URL for OIDC-authenticated users with support for RP-Initiated Logout
• Fix compatibility with Auth0 for OpenID-Connect authentification. See ramosbugs/openidconnect-rs#23
• updated sql parser: https://github.com/apache/datafusion-sqlparser-rs/blob/main/changelog/0.60.0.md
• updated apexcharts to 5.3.6:
  • apexcharts/apexcharts.js@v5.3.0...v5.3.6
  • https://github.com/apexcharts/apexcharts.js/releases/tag/v5.3.6
• re-add the lime color option to charts
• update default chart color palette; use Open Colors
  • 
• re-enable text drop shadow in chart data labels

Merry Christmas and a happy new year!

performance improvements, bug fixes, backwards incompatible variable

handling changes

• OIDC login redirects now use HTTP 303 responses so POST submissions are converted to safe GET requests before reaching the identity provider, fixing incorrect reuse of the original POST (HTTP 307) that could break standard auth flows.
• SQLPage now respects HTTP accept headers for JSON. You can now easily process the contents of any existing sql page programmatically with:
  • curl -H "Accept: application/json" http://example.com/page.sql: returns a json array
  • curl -H "Accept: application/x-ndjson" http://example.com/page.sql: returns one json object per line.
• Fixed a bug in sqlpage.link: a link with no path (link to the current page) and no url parameter now works as expected. It used to keep the existing url parameters instead of removing them. sqlpage.link('', '{}') now returns '?' instead of the empty string.
• sqlpage.fetch(null) and sqlpage.fetch_with_meta(null) now return null instead of throwing an error.
• New Function: sqlpage.set_variable(name, value)
  • Returns a URL with the specified variable set to the given value, preserving other existing variables.
  • This is a shorthand for sqlpage.link(sqlpage.path(), json_patch(sqlpage.variables('get'), json_object(name, value))).
• Variable System Improvements: URL and POST parameters are now immutable, preventing accidental modification. User-defined variables created with SET remain mutable.
  • BREAKING: $variable no longer accesses POST parameters. Use :variable instead.
    • What changed: Previously, $x would return a POST parameter value if no GET parameter named x existed.
    • Fix: Replace $x with :x when you need to access form field values.
    • Example: Change SELECT $username to SELECT :username when reading form submissions.
  • BREAKING: SET $name no longer makes GET (URL) parameters inaccessible when a URL parameter with the same name exists.
    • What changed: SET $name = 'value' would previously overwrite the URL parameter $name. Now it creates an independent SET variable that shadows the URL parameter.
    • Fix: This is generally the desired behavior. If you need to access the original URL parameter after setting a variable with the same name, extract it from the JSON returned by sqlpage.variables('get').
    • Example: If your URL is page.sql?name=john, and you do SET $name = 'modified', then:
      • $name will be 'modified' (the SET variable)
      • The original URL parameter is still preserved and accessible:
        • sqlpage.variables('get')->>'name' returns 'john'
  • New behavior: Variable lookup now follows this precedence:
    • $variable checks SET variables first, then URL parameters
    • SET variables always shadow URL/POST parameters with the same name
  • New sqlpage.variables() filters:
    • sqlpage.variables('get') returns only URL parameters as JSON
    • sqlpage.variables('post') returns only POST parameters as JSON
    • sqlpage.variables('set') returns only user-defined SET variables as JSON
    • sqlpage.variables() returns all variables merged together, with SET variables taking precedence
  • Deprecation warnings: Using $var when both a URL parameter and POST parameter exist with the same name now shows a warning. In a future version, you'll need to explicitly choose between $var (URL) and :var (POST).
• Improved performance of sqlpage.run_sql.
  • On a simple test that just runs 4 run_sql calls, the new version is about 2.7x faster (15,708 req/s vs 5,782 req/s) with lower latency (0.637 ms vs 1.730 ms per request).
• add support for postgres range types

SQLPage v0.39.1 released !

• More precise server timing tracking to debug performance issues
• Fix missing server timing header in some cases
• Implement nice error messages for some header-related errors such as invalid header values.
• compress_responses is now set to false by default in the configuration.
  • When response compression is enabled, additional buffering is needed. Users reported a better experience with pages that load more progressively, reducing the time before the pages' shell is rendered.
  • When SQLPage is deployed behind a reverse proxy, compressing responses between sqlpage and the proxy is wasteful.
• In the table component, allow simple objects in custom_actions instead of requiring arrays of objects.
• Fatser icon loading. Previously, even a page containing a single icon required downloading and parsing a ~2MB file. This resulted in a delay where pages initially appeared with a blank space before icons appeared. Icons are now inlined inside pages and appear instantaneously.
• Updated tabler icons to 3.35
• Fix inaccurate ODBC warnings
• Added support for Microsoft SQL Server named instances: mssql://user:pass@localhost/db?instance_name=xxx
• Added a detailed performance guide to the docs.

SQLPage v0.39.0

• Added support for executing SQL for URL paths with additional extensions.
  For example, creating sitemap.xml.sql will execute the SQL file when visiting example.com/sitemap.xml.

• Error messages now display source line information even when the database does not return a precise error position. In such cases, the entire problematic SQL statement is referenced.

  • 

• The shell with a vertical sidebar now supports active elements, similar to the horizontal header bar.

  • 

• Added new properties (edit_url, delete_url, and custom_actions) to the table component, making it easy to add icon buttons for editing, deleting, or performing custom actions. Thank you, @Phoenix79-spec for implementing this !

  • 

• SQLPage now sets the Server-Timing header in development mode. This allows you to identify performance bottlenecks by opening your browser’s network inspector, selecting a slow request, and viewing the Timing tab.

  • 

• Fixed a memory corruption issue leading to crashes in the built-in ODBC driver manager.

• ODBC: Fixed support for using globally installed system drivers by name on Debian-based Linux distributions. This means you can reference drivers by their name instead of having to provide the full path to the driver's .so file on these distributions.

• Added a new login component to create visually appealing login forms easily. Many thanks to @olivierauverlot for his contribution !

  •