🎵 Schemas'll never be the same. That's just the way it is... Changes. 🎵

TLDR

We improve schema evolution safety with enhancements to the schema pushing system, resulting in more flexible and reliable database structure upgrades

Another step towards the safest and easiest schema migrations in any database

This week we made some important improvements to the schema pushing system. Triplit has always had built-in systems and tooling for making changes to your schema quick and easy in development and then safe and smooth in production. These tools are now faster and more complete, leaving you equipped to run schema updates in production with a continuous deployment pipeline.

Warnings = Errors in production

Previously, changes to your schema that were determined to be backwards incompatible but did not violate existing data in the database would be logged but would not prevent the updated schema from being applied. While this is a great feature for iterating on your schema quickly in development, in production, you want to evolve your schema as safely as possible and catch any changes that could cause issues with existing clients that haven't been properly updated.

You can now, optionally, get triplit schema push to throw an error on any backwards-incompatible change with the flag --failOnBackwardsIncompatibleChange. You likely want this flag to be set if you're automatically pushing your schema to production in a CI/CD system like Github Actions.

Other Improvements

Faster data validations

In order to ensure there are no conflicts between the changes to a collection's schema and the entities already in the collection, Triplit runs a series of validations. This week we upgraded these validations to utilize newer features in the Triplit query engine, which should make schema changes to large databases take significantly less time to process.

Modifying relations in your schema

When you define relations in a schema, they can then be used directly in queries issued from the client or over the HTTP API. This means that if you remove relations from your schema, you can incidentally cause queries to start failing if you haven't informed or updated all callers before making the change. We previously prevented these updates but now they are categorized with other backwards incompatible changes but aren't blocked (unless failOnBackwardsIncompatibleChange is set).

As with all other backwards incompatible schema changes, you can read about the specific situations and remedies in our docs.