CrateDB supports zero-downtime schema changes through its dynamic object column types. Tables can be configured with three object policies: STRICT (fixed schema, all keys pre-declared), DYNAMIC (new keys auto-added and indexed on first insert), and IGNORED (data stored without schema enforcement or indexing). This is especially useful for IoT workloads where device firmware updates can change the shape of incoming data unpredictably. Unlike traditional RDBMS systems where an ALTER TABLE triggers downtime risks and complex change management procedures, CrateDB handles new columns automatically at insert time with no human intervention required.
Table of contents
CrateDB's Dynamic Objects Avoid Outages, Downtime, and Human Intervention, Saving Time and MoneyConclusionQuestions this post answers
How does CrateDB handle schema changes without downtime?
CrateDB supports DYNAMIC object columns that automatically accept and index new keys on first insert, inferring the data type from the first value seen. No ALTER TABLE statement is needed — the schema updates itself at runtime. An IGNORED object policy also exists for storing arbitrary data without indexing or schema enforcement, useful when data shape is completely unpredictable. Teams managing live schema evolution track database patterns like this on daily.dev.
What is the difference between OBJECT(STRICT), OBJECT(DYNAMIC), and OBJECT(IGNORED) in CrateDB?
STRICT requires all keys to be pre-declared; unknown keys are rejected and all values are indexed. DYNAMIC is the default — new keys are accepted, added to the schema, and indexed on first sight with type inferred from the first value. IGNORED stores all incoming data without schema enforcement or indexing, useful for unpredictable payloads like IoT device stats that vary by firmware version. Developers choosing between CrateDB object policies for their data model find relevant comparisons on daily.dev.