Postgres vs NoSQL for SMB automation backends
Why Postgres wins for almost every SMB automation backend, and the few cases where a document store is actually the right call.
Default to Postgres
For SMB automation backends, the answer is almost always Postgres. Here is why we keep landing there.
What you actually need
An SMB automation backend reads and writes:
- Customers, orders, invoices, products
- Webhook events from third parties
- Job status and audit logs
- Sync state between systems
Every one of those benefits from a schema, transactions, joins, and constraints. That is exactly what relational databases were designed for.
The "I need flexible data" trap
The most common reason teams reach for MongoDB or DynamoDB is "the data shape will change." It almost never does in the way they think.
If your data shape genuinely changes — say, you accept arbitrary JSON from a partner — Postgres has jsonb with proper indexing. You get document flexibility and the rest of Postgres for free.
We have shipped client projects with mixed structured columns and jsonb payloads. The team gets the flexibility, and ops still get backups, replication, and migrations.
When NoSQL is the right call
- Event streams at very high volume (>10k events/second sustained) → Kafka or DynamoDB
- Real-time chat or presence → Redis or Firestore
- Globally distributed reads with eventual consistency → DynamoDB, Spanner, or CockroachDB
- Massive document corpora for search → Elasticsearch or OpenSearch (as a secondary store)
None of these are typical SMB workloads. If you are an SMB and your traffic looks like a normal business — thousands to tens of thousands of operations a day — Postgres is plenty.
Operational comfort matters
Postgres has:
- Decades of operational tooling
- Reliable backups (pg_dump, WAL-G, point-in-time recovery)
- Replication that just works
- The largest pool of hireable expertise
NoSQL stores vary wildly here. Some are great. Some will surprise you in production.
What we actually ship
Postgres, with jsonb for genuinely flexible payloads, Redis for caching and Celery, and a search index (Postgres FTS or Meilisearch) when the client needs real search.
That handles 95% of SMB workloads without ceremony.