This is a reverse chronological summary of TinyJoin releases and their public compatibility boundaries. Every entry states what upgrading to it requires, so check the entries between the version in use and the target before upgrading. A release that needs no action says so explicitly.
Subscriptions and statement results now report which rows changed, not only which tables. A TablesChangedEvent and every Results carry a keys map of table name to the primary keys that changed, so a listener can refresh individual rows instead of re-reading a table. Keys are reported for writes from any connected Client, which makes a change made in another tab resolvable to individual rows. See refreshing individual rows.
Reporting is a bounded best effort, and the changed-table list stays authoritative. A table appears in keys only when every key it changed fits the bound of 1,000 keys per table; a table that changed more rows is absent rather than partially listed, so an absent table means its rows cannot be named and must be re-queried. keys is always empty alongside reset: true. Code that assumes keys are present will silently miss large writes, so handle the absent case.
The Worker protocol version moves from 7 to 8. Client and Worker ship together and are upgraded together by a normal install, so this affects only a deployment that pins or caches a Worker file independently of the client bundle. A mismatched pair fails cleanly with PROTOCOL_MISMATCH rather than misreading a result. Applications using tinyjoinOffline() are unaffected: the plugin revisions both files by content, so a rebuild replaces them together.
Upgrading from v0.1.0 needs no action. Install, rebuild, and redeploy. Persistent storage is unchanged: the page format remains format 2, so an existing database opens with no migration and no OPFS namespace change. The keys field is additive, so application code that ignores it behaves exactly as it did before.
Grouped and aggregate queries now use a secondary index when their predicate supplies every column of one, instead of always scanning the table. Results are unchanged, because the predicate is still evaluated for each candidate row. Because the scan limit counts candidate rows, a grouped query that previously exceeded QUERY_WORK_LIMIT_EXCEEDED on a large table may now succeed.
tinyjoin/node no longer fails to start when the parent process runs with a flag that Node rejects for a worker thread, such as the --stack-trace-limit that several test runners set. Inherited flags are dropped rather than the database failing to open.
The new Node entry point, tinyjoin/node, opens in-memory databases in Node.js 22 or later. It constructs a Worker thread and loads WASM automatically, returning the same Client API without additional dependencies. Each Client owns an independent database; filesystem persistence is not included.
Persistent storage breaks compatibility with v0.0.5. The npm v0.0.5 release uses page format 1; v0.1.0 uses page format 2. Opening a v0.0.5 database with v0.1.0 fails with UNSUPPORTED_PAGE. There is no automatic migration, and changing the OPFS name does not copy existing data.
- For data that can be reconstructed, use a new OPFS namespace, for example change
opfs://my-app-v1toopfs://my-app-v2, and rebuild the database. The old namespace remains intact. - To retain existing data, export the application's known tables using a client pinned to
tinyjoin@0.0.5before upgrading. Create the schema in a new namespace with v0.1.0, import rows with parameterized statements, and verify the data before retiring the old database. TinyJoin does not yet provide a general database export or migration API. - New apps generated by create-tinyjoin v0.1.0 target
tinyjoin@^0.1.0and use a-db-v2storage name. Updating the generator does not migrate applications it generated previously.
This release also makes predicate and assignment type validation consistent across reads and writes, compares heterogeneous JSON values consistently, and bounds shared parameter-graph traversal and expanded SQL bindings before copying values. Append-only transactions now validate new row statements incrementally, including unique-index checks; mixed writes retain complete staged write-set validation.
Selective multi-table joins now use their actual comparison count rather than a worst-case Cartesian estimate. Scan, build-row, result, memory, and shared script-work limits remain in force.
Page checksum calculation is faster while preserving the stored checksum values, storage format, and corruption checks. This improves mixed writes and populated startup; the repository's workload measurements retain the before/after samples and runtime hashes.
UPDATE and DELETE now use direct primary-key lookup for exact complete key predicates, including staged transaction rows. Other predicates retain their scan path, and statement validation and constraint checks remain in force.
Persistent startup avoids a redundant table scan for unique indexes whose columns are all NOT NULL. Table validation and complete index-entry checks remain in force; nullable indexes and indexes without uniqueness retain the existing count scan.
Duplicate output names in simple projections and RETURNING now fail consistently with INVALID_QUERY before execution. LIMIT and OFFSET reject nonnumeric parameter values consistently in ordinary, aggregate, and join queries, including JSON objects shaped like internal prepared placeholders.
Persistent Clients now coordinate automatically across tabs and within a page. One elected Worker owns the database; operations, prepared statements, and notifications follow it through handover. Callback transactions exclude other Clients for their duration. In-flight operations interrupted by owner loss reject without automatic replay, and incompatible releases reject explicitly.
The optional tinyjoin/vite build plugin precaches a complete production application, including lazy Worker, OPFS, and WASM assets. New starter apps enable it by default. Updates wait for old controlled tabs to close; existing service workers can use its generated manifest and helper instead. See the offline guide.
This release establishes TinyJoin as a standalone, SQL-first browser database package.
create() opens the packaged dedicated Worker and WebAssembly engine with no application Worker boilerplate.- Memory and persistent OPFS databases use one bounded page-native engine.
- The JavaScript client provides parameterized queries, atomic scripts, callback transactions, reusable prepared statements, and table-level change subscriptions.
- Typed tables support primary keys, maintained secondary and unique indexes, bounded schema additions, aggregates, and left-deep inner and left joins.
Resultsuse a familiarrows,fields,affectedRows,command, androwCountshape, with TinyJoin revision and changed-table metadata.- The published package includes its runtime, Worker, WASM, declarations, compatibility guide, README, release notes, and agent guidance.
TinyJoin remains experimental and deliberately smaller than PostgreSQL. This release does not include a PostgreSQL server or wire protocol, hosted service, remote replication, or offline-write synchronization.