Hacker News Reader

Comment by lars512 | Hacker News Reader

Related question: when you're using databases with great offline sync protocols like this, how do you do schema evolution of your DB, especially in the face of different client versions that you cannot upgrade in lockstep?

My context here is having worked in the past on a mobile health app, and recalling all the pain we had around this problem.

View on HN

Only create new tables, don't make breaking changes to existing tables. If needed dual write both versions. Looks a lot like a live migration (zero downtime) due breaking change to a SQL DB, except you have to keep the logic longer because you're at the customer's mercy of when the switchover happens.

Also it's important to have a table that is used to coordinate latest version. If you make a breaking change have the client that is behind to ask the user to upgrade. You can also tie this into how long you keep the dual write/read around with a min version supported across all clients.

This is a great question! The short answer is by maintaining backwards compatibility in your schema--it's basically the easiest way to guarantee compatibility. We have warnings in place to let you know when you've made a change that isn't backwards compatible, you can read about it in our docs: https://www.triplit.dev/docs/schemas/updating#pushing-the-sc...

However, overtime this can naturally lead to a mess of a schema definition that has a lot of confusing names. We haven't released a solution to fix this yet but we're working on a few things that should make this less painful. For background on the various approaches, the Cambria doc is an amazing resource: https://www.inkandswitch.com/cambria/

Lenses make total sense. You don't have to maintain lenses for all past versions, just a rolling set with old ones scheduled for deprecation announcements and a sunset schedule.

I think some clients (like the server) must be able to sync with very old schemas because the user might have forgotten their phone in a drawer for two years. Each client just migrates itself asap.

I don't think any user who leaves their unsynced data sitting in a drawer for more than a year can reasonably expect it to sync to a shared database, not just because of schema incompatibility but more so because of conflict resolution (imagine expecting your PR based on a two year old git commit to be accepted to a very active project). Just give them a report of the diff (the unsynced changes) so they can redo them via the latest client manually.

I would say having a built in way to define and support historic migrations would be a pretty killer feature. Saves everyone inventing their own way of managing migrations.

Reply on news.ycombinator.com