Should I use PostgreSQL if I expect schema changes every week?

Yes — PostgreSQL is usually a very good choice even if your schema changes weekly.

A few reasons:

• It handles schema evolution well: adding/removing columns, indexes, constraints, and tables is normal in PostgreSQL.
• Strong migrations ecosystem: tools like Flyway, Liquibase, Alembic, Prisma, Django migrations, etc. work well with Postgres.
• Reliable and mature: it’s a solid default for applications that are still evolving.
• Flexible enough for change: you can start with a simple schema and refine it over time.

That said, weekly schema changes can mean one of two things:

If you mean “the application is evolving quickly”

PostgreSQL is a great fit. Just use migrations and keep changes backward-compatible when possible.

If you mean “the data model is uncertain and changes constantly”

PostgreSQL can still work, but you may want to:

• use JSONB for parts of the data that are unstable,
• avoid over-normalizing too early,
• design migrations carefully to minimize downtime,
• consider whether you need a document database for some subdomains.

Practical advice

If you choose PostgreSQL:

• use a migration tool from day one,
• make migrations backward-compatible,
• avoid dropping/renaming columns in a breaking way unless you can coordinate deploys,
• use JSONB for fields that are not yet stable,
• add indexes only where needed.

Bottom line:
If schema changes every week, PostgreSQL is still often the best choice. Frequent change is not a reason to avoid it; it’s a reason to use migrations and design for evolution.

If you want, I can also give you a PostgreSQL vs MongoDB for fast-changing schemas comparison.