Your data format stays readable. Forever.

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.

Field-level sync conflicts, not silent winners

Local-first software has one extra responsibility: two devices can edit nearby data before they sync. Our merge policy is designed around fields and timestamps instead of "last file wins." If your laptop updates a birthday reminder while your phone adds a note, those are separate facts and should both survive. When two edits truly conflict, the app should surface the conflict rather than silently throwing one side away.

The policy is explicit by data type. Scalar fields such as a reminder interval can use last-write-wins, with the discarded value kept in changelog history. Sets such as tags and group membership merge by union, with tombstones for deletions so removed items do not quietly reappear. Interaction history is append-only: two devices adding two separate events should keep both. Long personal notes are manual-review fields; if two devices edit the same note, Endearist should ask instead of inventing a semantic merge.

That sounds small, but it is the difference between "sync succeeded" and "sync succeeded without erasing the fact you cared enough to write down." We would rather show a rare conflict review than silently choose the wrong version of a personal memory.

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.

That is the practical meaning of schema stability: your relationship history is not trapped behind our future business model. Updates can improve the app, but they do not get to make your old memories unreadable.

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. No automatic merge of long personal notes when the app cannot know which version is the truth.

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.