SQL vs NoSQL for SaaS: When to Use Each (And Why We Chose Both)

One interesting thing we learned while scaling a SaaS platform:

SQL vs NoSQL is rarely an “either-or” decision.

We ended up using both.

Initially, everything was running on PostgreSQL with Rails.

And honestly, for a long time, it worked perfectly:
* Transactions were reliable
* Reporting was predictable
* Data consistency was easy to maintain

But as product usage changed, new patterns started appearing.
One feature started generating millions of activity events every week.

Storing and querying that data in the main relational DB started affecting:
* Reporting performance
* API response times
* Background job processing

That’s where we realised:
Not all data behaves the same way.

So we changed the architecture:
* PostgreSQL continued handling transactional data
* NoSQL was introduced for high-volume activity/event storage

After separation:
* Core API performance became stable again
* Reporting queries improved significantly
* Event ingestion scaled without impacting transactional flows

The important learning:
SQL and NoSQL solve different problems.

Relational databases are excellent for consistency and relationships.

NoSQL becomes useful when scale, flexibility, or write-heavy workloads start behaving differently.

The mistake is not choosing one over the other.

The mistake is forcing all workloads into the same data model.