Privacy · Schema stability
Your data format stays readable. Forever.
You invest hours in your contacts, notes, and interaction history. We are responsible for keeping that data readable across app updates — not just through the next version, but permanently.
The Monica-Chandler problem
Apps that manage personal data have a structural trust problem: users never quite know whether an update will silently break their data. Monica, a popular open-source personal CRM, has changed its database schema multiple times over the years — and users who didn't export regularly or watch for migration errors occasionally ended up with inconsistent data.
We call this the "Monica-Chandler problem": the anxiety that an update might silently overwrite Julia's knee surgery note, Mike's nickname, or three years of interaction history because the migration missed an edge case.
Our promise: that doesn't happen with Endearist. Here is specifically how we enforce it.
What migration discipline looks like in practice
Schema dumps before every version bump
Before we increment the database version number, a complete schema dump is committed to the repository. This is a hard technical rule — no version bump without a committed schema snapshot. If you look in ten years at what schema v1.4.2 used, you'll find it in the git log.
Migrations run forward only, reversible via JSON
All database migrations run in one direction: from old to new. We don't write migrations that irreversibly delete or transform data without first creating a pre-migration snapshot. Before each migration, a complete JSON export of the affected data is saved — as a safety net in case the migration fails or contains a bug.
Concretely: if a migration fails, the pre-migration snapshot is automatically restored. You get an error message but no data loss. This is not optional — it's part of the migration pipeline.
Schema version in every backup file
Every automatic backup contains the schema version it was created under. This means: if you open a backup from v1.2.0 with Endearist v2.5.0, the app knows exactly which migrations to apply — and it does so in sequence, verified, with pre-step snapshots.
What this means in practice
Forward compatibility across releases
Every release candidate must successfully run all migration steps from v1 to the current version. This is checked as part of the continuous integration pipeline — no release ships if the migration round-trip fails. "All migrations from v1 to today must round-trip" is one of the pre-merge gates in our engineering documentation.
Your data format is not a proprietary secret
The SQLite schema is documented. The Markdown export format is public. Even if Endearist stopped existing tomorrow, you could open your data with a standard SQLite tool and read it — without proprietary software, without us.
What we promise and what we don't
We promise: every new version of Endearist can open data from any older version. Every migration is tested. No silent dropping of data fields without an explicit user warning.
We don't promise: backward compatibility — an older app version may not be able to open data created by a newer version. That would be technically difficult to maintain and gives you no practical benefit, since you can always update to the latest version.