I'm frustrated with MySQL for this app. Is PostgreSQL actually better for scaling and schema changes?

Short answer: often yes, but not automatically.

If your pain is around schema changes, complex queries, consistency, and long-term maintainability, PostgreSQL is usually the better choice. If your pain is mostly around operational simplicity and existing tooling, MySQL can still be perfectly fine.

Where PostgreSQL is often better

1. Schema changes and evolution

Postgres tends to handle evolving schemas more gracefully, especially for apps that grow in complexity.

• Stronger support for rich data types
• Better constraints and enforcement
• Good support for JSONB if you need flexible fields
• Generally nicer tooling for migrations and refactoring

That said, DDL can still lock tables depending on the change and table size. So “better” doesn’t mean “free.”

2. Complex querying

If your app is moving beyond simple CRUD:

• CTEs
• window functions
• recursive queries
• better indexing options
• more expressive SQL

Postgres usually wins here.

3. Data integrity

Postgres is usually stronger when you want the database itself to prevent bad data.

• stricter defaults
• more robust constraints
• better transactional behavior in practice

4. Extensibility

Postgres has a reputation for being highly extensible and future-proof:

• custom types
• extensions like PostGIS
• advanced indexing
• stored procedures in multiple languages

Where MySQL may still be fine or better

1. Simpler workloads

If your app is mostly:

• basic reads/writes
• simple indexes
• straightforward joins

then MySQL may be just as good.

2. Team familiarity

If your team already knows MySQL well, switching databases can be a bigger win or bigger headache depending on skill level.

3. Existing ecosystem

Your hosting, ORM, and operational setup might be optimized for MySQL.

Scaling: the important nuance

People often say “Postgres scales better,” but the real answer is:

• Postgres scales very well vertically
• MySQL can scale very well too
• neither one magically solves horizontal scaling

For many apps, the bigger scaling bottlenecks are:

• bad queries
• missing indexes
• too much coupling
• poor caching
• noisy migrations
• connection limits
• write contention

Postgres may give you more tools and better ergonomics, but architecture matters more than the logo on the database.

When I’d lean PostgreSQL

I’d strongly consider Postgres if:

• your schema changes frequently
• your queries are getting complex
• you need strong data integrity
• you want better support for JSON and relational data together
• you expect the app to grow in complexity over time

When I’d stay on MySQL

I’d stay with MySQL if:

• the app is stable and simple
• your team is highly experienced with it
• switching would create more risk than value
• your current bottleneck is elsewhere

Practical advice

If you’re already frustrated, ask:

1. What exactly is painful?
   • migrations?
   • locking?
   • query complexity?
   • ORM limitations?
   • performance?
2. Is the database actually the bottleneck?
3. Can you fix the pain with better schema design or migration strategy first?
4. Would moving to Postgres reduce future friction enough to justify the migration cost?

Bottom line

Yes, PostgreSQL is often better for apps that are growing in complexity and changing schema frequently.
But for raw “scaling,” it’s not a silver bullet. The best choice depends on whether your current pain is really a database limitation or an architecture/process issue.

If you want, I can help you decide with a MySQL vs PostgreSQL checklist based on your app type and current problems.