What Local Storage Actually Buys You
Meetily’s local-storage question begins when the transcription worker has produced timestamped text: what becomes durable, where does it live, and what can be recovered or reused later? This chapter follows a meeting through SQLite, its meeting-folder artifacts, auto-save, shutdown, import, retranscription, recovery, and deletion. The goal is to distinguish control and integrity from stronger claims—such as application-level encryption or perfect crash durability—that the current code does not establish.
That distinction is essential to a local-first design. Keeping a transcript on the user’s machine is valuable only if the user can find it, relate it to the audio, recover it after an interruption, and remove it when retention ends. Meetily addresses those needs with two connected storage layers rather than one universal record.
Two layers of a meeting record
The first layer is a local SQLite database in the application data directory. It contains the meeting record, transcript rows, settings, summary-process state, and the transcript input used for summary work. A meeting has an identifier, title, timestamps, and an optional folder path. Each transcript row carries text and recording-relative timing fields. Those timing fields are what let the interface associate a sentence with a position in the audio instead of treating the transcript as an unanchored block of text.
The second layer is the meeting folder that the recording path creates on disk. It can contain the mixed audio, metadata, and a structured transcript JSON file. The folder is named from the meeting name and a timestamp, while the database keeps the path needed to find it. This duplication is deliberate. SQLite makes meeting lists, search, pagination, configuration, and transactional updates convenient. Ordinary files make the recording and transcript visible to the user’s file system and usable by import, recovery, or external retention procedures.
The two layers do not have identical contents or identical lifecycles. A database row can exist while audio finalization fails. A transcript JSON file can be updated during an active session before the final database save. An audio file can remain available for retranscription even when its transcript rows are replaced. The right question is therefore not “where is the meeting?” but “which representation of the meeting am I trying to preserve or change?”
Meetily initializes the SQLite database when the supported desktop application starts. It creates the application-data directory if needed, creates a new database when none exists, and runs the committed migrations. The startup logic can also detect an older database file and copy it into the current SQLite location for migration. On shutdown, the database manager attempts a write-ahead-log checkpoint and closes the connection pool. These are lifecycle controls for database integrity and compatibility; they do not make the surrounding media files part of the same transaction.
The database repositories use transactions for operations that need to stay coherent. Creating a meeting with its transcript segments either commits the set or rolls it back. Replacing transcripts during retranscription also occurs inside a transaction: old rows are deleted and new rows are inserted before the replacement becomes visible as a completed database operation. Deleting a meeting removes related transcript chunks, summary-process rows, transcript rows, and finally the meeting row in a controlled order.
That last point contains an important boundary. The examined deletion repository code governs database records. It does not, by itself, prove that the corresponding meeting folder, audio file, metadata JSON, or checkpoint remnants are removed from the file system. A user who needs complete retention enforcement must treat database deletion and file deletion as separate questions. Local ownership makes that inspection possible, but it does not make it automatic.
Auto-save determines how much of the file layer is created during recording. When it is enabled, Meetily creates a meeting folder with a checkpoint directory and starts an incremental saver. The recording pipeline sends the mixed audio—not the separate raw microphone and system streams—to that saver.