Skip to content

Update vendored SQLite amalgamation to 3.53.2#306

Open
stumpylog wants to merge 1 commit into
asg017:mainfrom
stumpylog:update-sqlite-amalgamation
Open

Update vendored SQLite amalgamation to 3.53.2#306
stumpylog wants to merge 1 commit into
asg017:mainfrom
stumpylog:update-sqlite-amalgamation

Conversation

@stumpylog

@stumpylog stumpylog commented Jun 11, 2026

Copy link
Copy Markdown

Summary

Updates the vendored SQLite amalgamation from 3.45.3 (2024) to 3.53.2 (2026), the current latest release:

  • scripts/vendor.sh: downloads 2026/sqlite-amalgamation-3530200.zip
  • Makefile: SQLITE_WASM_VERSION=3530200, SQLITE_WASM_YEAR=2026

tests/minimum/ is intentionally left at 3.31.1 since it exists to verify the minimum supported SQLite version. All SQLITE_VERSION_NUMBER gates in the source are minimum-version checks (3.38/3.44) already satisfied by the previous vendor, so no behavior changes.

Validation

  • make loadable and make static build cleanly against the 3.53.2 vendor.

  • Full Python suite passes: 478 passed, 132 skipped (feature-gated), 204 snapshots passed.

  • WASM verified end-to-end with emcc: SQLite 3.49+ switched its build to autosetup, but everything make wasm relies on still works (./configure --enable-all, make sqlite3.c, the jswasm/sqlite3.mjs / jswasm/sqlite3.wasm targets, and the sqlite3_wasm_extra_init.c= override). A node smoke test against the resulting build returns correct vec0 KNN results:

    sqlite_version: 3.53.2
    vec_version: v0.1.10-alpha.4
    knn: [{"rowid":1,"distance":1},{"rowid":2,"distance":3.873}]
    

One note for local (non-emsdk) wasm builds: 3.53's ext/wasm requires a config.make that the SQLite configure script only generates when it detects an emsdk install (EMSDK env var / --with-emsdk). The release CI workflow uses setup-emsdk, which provides that, so make wasm works there unchanged.

What's new between 3.45.3 and 3.53.2

Full release history: https://sqlite.org/changes.html

A few additions in this range are directly useful to sqlite-vec (none are used by this PR; they would need SQLITE_VERSION_NUMBER / sqlite3_libversion_number() guards like the existing 3.38/3.44 gates, since the minimum supported SQLite remains 3.31.1):

  • SQLITE_PREPARE_FROM_DDL (3.53.0): new sqlite3_prepare_v3() flag that "permits virtual table implementations to safely prepare SQL statements that are derived from the database schema". vec0 prepares many statements built from schema-derived shadow table names, so this is a natural hardening fit.
  • sqlite3_set_errmsg() (3.51.0): API added specifically "for use by extensions" to set error messages.
  • Virtual table DISTINCT optimization (3.53.0): vtabs can now optimize DISTINCT when the result set does not exactly match the ORDER BY clause (relevant to xBestIndex).
  • sqlite3_str_truncate() / sqlite3_str_free() (3.53.0): small additions to the sqlite3_str API that sqlite-vec already uses for SQL construction.
  • SQLITE_PREPARE_DONT_LOG (3.48.0): suppresses error-log noise when using prepare to test-compile SQL.
  • 64-bit WASM support (3.51.0): the wasm build now also produces 64-bit variants; the canonical 32-bit builds that make wasm consumes are unchanged.

One behavior change worth knowing about: as of 3.53.0, floating-point-to-text conversion rounds to 17 significant digits by default instead of 15 (configurable via SQLITE_DBCONFIG_FP_DIGITS). This only affects SQLite's own float rendering, and the full test suite (including 204 snapshots) passes against 3.53.2.

Bumps scripts/vendor.sh and the WASM build's SQLITE_WASM_VERSION from
3.45.3 (2024) to 3.53.2 (2026).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant