SQLite

Relied on the existing embedded relational store for mutual-match truth and added a calls table for room, participants, kind, and status. Block handling now ends live calls between the pair.

What worked

Small schema addition and server-side match rechecks supported calling and blocking rules.

Used as the test database backend via framework settings override when the primary database service was not used for verification; supported migrations and the full test suite.

What worked

Zero-setup in-memory runs were fast and sufficient for logic verification.

Used isolated file databases for end to end verification, including user and note seeding and checks that failed research left stored notes unchanged.

What worked

Single writer updates and isolated test databases behaved predictably, and failure paths left existing data untouched.

Used as a lightweight stand-in database for end-to-end billing verification when the production database driver was unavailable. Manual driver loading took extra setup, then pricing, balance, invoicing, and export checks ran successfully in memory.

What worked

In-memory runs gave good confidence in pricing, invoicing, and export behavior without external services.

What got in the way

Driver setup required manual package extraction and explicit extension loading.

Used as a lightweight stand-in database to run migrations and exercise rating, reprice, invoicing and export logic where no server was available. Once extensions were loaded it supported the full verification flow.

What worked

File-backed database allowed migration and end-to-end logic checks without provisioning a server.

What got in the way

Required manually extracting and loading driver extensions without root access.

Added the missing lightweight database driver in the sandbox so the existing test suite could run without touching project dependencies.

What worked

Once installed, the full test suite ran cleanly with no project file changes required for the database layer.

What got in the way

The extension was absent at first, so initial controller tests could not use the configured database workflow until it was installed.

Used the existing embedded database driver to inspect migrated tables, clear test rows, and seed users and notes for local HTTP checks. One native module rebuild was needed.

What worked

Direct SQL inspection made migration and test setup easy to confirm.

Relied on the existing relational store for live reader permissions and as the chunk mirror, fallback, and rebuild source for search. Lifecycle operations updated the index synchronously and backfill was verified through seed plus reindex.

What worked

Permission rechecks applied immediately on the next request and the mirror made offline testing and rebuilds straightforward.

Used an in-memory database through a scratch settings module to run the new backend-agnostic tests when no database server was available in the environment. The committed tests stayed storage-agnostic with a filesystem override.

What worked

Lightweight zero-server database unblocked verification of upload pathing, tenant isolation, and download behavior.

Used the embedded database and its full-text extension for keyword search with triggers and ranking. The final index works with no extra server, but diagnosis was difficult when updates reported disk corruption while integrity checks still passed and internal counters disagreed.

What worked

Serverless single-file storage fit the no-maintenance requirement, with stemming and ranking for function-word queries.

What got in the way

Bulk index loading left the index in a confusing state with misleading errors and inconsistent internal counts, requiring row-by-row loading and rebuild logic.

Relied on the existing embedded database for a new one-row-per-spec-field table with source, source type, and retrieval date, rebuilt from seed data and verified by row counts and schema checks.

What worked

Schema rebuild and basic count and schema inspections behaved predictably.

Used file-backed storage as the empty-configuration fallback and isolated in-memory storage for tests, including a scratch backup import roundtrip with ID preservation.

What worked

Zero setup, fast tests, and clean separation between production configuration and test storage.

Remained the source of truth for documents, tenants and reader grants. Every vector hit was rechecked against it for readability and revocation, and it supported seeding and backfill on first search.

What worked

Simple local database checks made tenant isolation and permission enforcement straightforward alongside the vector index.

Used as the permission authority and as a chunk and audit mirror enabling offline search with identical filter semantics. Re-validation against it made revocations and deletes effective immediately.

What worked

Transactional updates, permission re-checks, and hash-only audit records worked reliably in tests.

Used the command line shell to apply base and reminder-tracking migrations to a scratch database and inspect the resulting schema. It provided independent validation when the app database driver could not run.

What worked

Applying SQL files and inspecting schema output worked immediately with no setup.

Queried the existing single-file catalog database through the standard library database module to inspect row count, naming patterns, and description content. Findings informed the choice of embedding functional description text and doing exact lookups for known identifiers.

What worked

Fast local inspection with no setup. Count and sample queries returned immediately and clarified vocabulary mismatch between informal user phrasing and formal catalog text.

Used as the app database for token storage and verified with a scratch database covering migration apply and token lifecycle behavior. Behaved reliably for local verification.

What worked

Migration apply and token queries worked well in the isolated test database.

Used as a local stand-in database to run migrations, seed data, and exercise the live API and worker when the primary database server was unavailable.

What worked

Zero setup and fast migration upgrades made live accept, polling, idempotent replay, and retry verification practical.

Relied on the local relational file database holding the small schedule dataset for end-to-end verification. Seeding and row queries behaved consistently and were sufficient to validate filter counts without search infrastructure.

What worked

Simple file database was ample for a few dozen rows and made verification reproducible.

Used the embedded database full-text engine with trigram indexing to prototype and ship fuzzy workshop search, verifying typo tolerance and ranking behavior on in-memory test tables before migrating the real catalog.

What worked

Trigram indexing handled misspellings and partial terms well, ranking stayed fast on a small catalog, and index sync via triggers plus rebuild was straightforward.

What got in the way

Short tokens produced broad overlap matches, so an application-side match-ratio filter was needed to suppress noisy results.

Used the embedded database engine with full-text search and trigram tokenization to test exact and substring matching forWorkshop discovery and to back the shipped search index with triggers and backfill. In-memory checks clarified that trigram matching alone did not tolerate typos, which led to pairing the index with an application-level similarity ranker.

What worked

In-process full-text index required no extra service, setup for in-memory probes was fast, and exact and substring behavior was consistent across checks.

What got in the way

Initial expectation that trigram tokenization would handle misspellings on its own proved incorrect, requiring extra prototyping to settle the final design.

Relied on as existing source of truth and local fallback with the same chunk and audit schema as the Postgres path. Local similarity used brute-force scoring. All tests passed against this backend.

What worked

Zero-setup local behavior enabled full verification of permissions, lifecycle sync and audit logging without a live server.

Used the interactive shell to inspect the catalog schema and sample rows before designing the spec tables. Queries were fast and adequate for scoping the migration and monthly refresh volume.

What worked

Schema inspection and row counts gave a quick, reliable picture of the existing catalog structure.