[unclebucknasty]

It's not Postgres, specifically, as much as any SQL or non-schemaless database, right?

And if we're saying that's a problem, then sounds like we're going back into the NoSQL debates from a decade ago.

Hopefully not.

I think it's better to understand your schema as much as possible, and have a sane process for applying changes when needed. Defining a schema forces you to think about what you're building.

OTOH, the idea that developers on a project are just going to throw whatever new attributes they need into a document as they go along is a recipe for bugs and inefficiency. Also, near-instant technical debt, as early work frequently survives longer than anticipated.

You also don't completely escape data changes without pain when using a NoSQL database. If for instance you change a string to an int you'd still need to figure out what to do with existing data, either via conversion or handling in-code.

[sgarland]

> Defining a schema forces you to think about what you're building.

YES. Thank you. Sit down with pencil and paper, write down a table name, and start putting attributes into it. Then define a PK, and ask yourself if every attribute is directly related to the PK (a user named foo has an id of 1, and lives in country bar). Repeat. Then ask yourself how you’d join the tables. If you find that something _could_ be represented as a join, but isn’t, consider doing so.

[jordanthoms]

Not quite any - in CockroachDB, all schema changes are non-blocking: https://www.cockroachlabs.com/docs/stable/online-schema-chan... . Yugabyte seems to be getting there with them also.

Still risks involved in migrations (mostly from the migration executing too quickly and creating high load in the cluster - the admission control system should have reduced this) and we have extra review steps for them, but it's been very useful to be able to migrate large tables without any extra application-level work.