One thing I usually do is keep a 'jsonb' column for cases where I need to support dynamic or evolving models in Postgres. That way I can keep the core schema well-defined — PKs and stable columns — while still having flexibility for attributes that might change over time.
I know this can easily turn into a “magic column” if you're not careful, but I try to keep the main domain properly modeled and handle validation at the application layer.
I follow a similar approach, especially for data that I'm not sure what it would look like at the moment of design. Usually, this is some kind of config, metadata, etc. What I do for sure, however, is add types that describe the actual data in the DB. This way, I know what it looks like.
And thank you so much for the feedback and for sharing your experience!
Actually brilliant article - i would call this “First Principles OLTP Design” - essential for the new developer in 2026 (every AI tool practitioner).
Thank you so much for the feedback! And I love the rephrasing! Will use it when I reference it.
Great post.
One thing I usually do is keep a 'jsonb' column for cases where I need to support dynamic or evolving models in Postgres. That way I can keep the core schema well-defined — PKs and stable columns — while still having flexibility for attributes that might change over time.
I know this can easily turn into a “magic column” if you're not careful, but I try to keep the main domain properly modeled and handle validation at the application layer.
I follow a similar approach, especially for data that I'm not sure what it would look like at the moment of design. Usually, this is some kind of config, metadata, etc. What I do for sure, however, is add types that describe the actual data in the DB. This way, I know what it looks like.
And thank you so much for the feedback and for sharing your experience!
Good read