LayerbaseLayerbase

Best Database for a SaaS MVP

PostgreSQLRedisDatabases

You're building a SaaS. You have users, subscriptions, maybe teams and permissions. You need to store relational data, query it reliably, and not wake up in six months wishing you'd picked something else. You open a browser tab, search "best database for SaaS," and immediately get pulled into a vortex of opinions about MongoDB vs PostgreSQL vs "it depends on your use case."

Let me save you the afternoon: just use PostgreSQL.

Contents

Just Use PostgreSQL

This isn't a hedged recommendation. PostgreSQL is the right database for your SaaS MVP.

It handles relational data (users, teams, subscriptions, invoices) with proper foreign keys, joins, and transactions. It handles semi-structured data with jsonb. It handles full-text search with tsvector and ts_query. It handles geospatial queries with PostGIS. It handles vector similarity search with pgvector. It handles recursive hierarchies with ltree or recursive CTEs.

Most of the things you'd reach for a second database to do, PostgreSQL already does. Not in a "technically possible if you hack it" way. In a "this is a mature, well-documented, production-tested feature" way.

Every major ORM supports it. Every managed hosting provider offers it. Every CI/CD platform has a PostgreSQL service container. The pg and postgres npm packages are rock solid. Drizzle, Prisma, and Kysely all have first-class PostgreSQL support. If you outgrow a single instance, you can add read replicas, use Citus for horizontal sharding, or migrate to CockroachDB (which speaks the PostgreSQL wire protocol) with minimal code changes.

You will not outgrow PostgreSQL before you have paying customers. You will probably not outgrow it for years after that.

Set Up PostgreSQL with SpinDB

SpinDB gives you a local PostgreSQL instance in one command. No Docker, no Homebrew postgres tap, no initdb ritual. (What is SpinDB?)

Install SpinDB globally:

bash
npm i -g spindb    # npm
pnpm add -g spindb # pnpm

Or run it directly without installing:

bash
npx spindb create saas-db --start  # npm
pnpx spindb create saas-db --start # pnpm

If you installed globally, create and start an instance:

bash
spindb create saas-db --start

PostgreSQL is the default engine, so you don't need the -e flag. That's intentional.

Get the connection string:

bash
spindb url saas-db
text
postgresql://postgres:postgres@localhost:5432/saas-db

Drop that into your .env and you're connected. Your ORM, your migration tool, your admin client: they all speak this connection string.

What PostgreSQL Handles Out of the Box

Here's a partial list of things SaaS teams commonly reach for separate tools to handle, that PostgreSQL does natively.

Relational data

Users, teams, subscriptions, invoices, permissions. Foreign keys, joins, transactions, constraints.

sql
CREATE TABLE teams (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  plan VARCHAR(50) NOT NULL DEFAULT 'free',
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  team_id INT REFERENCES teams(id),
  role VARCHAR(50) NOT NULL DEFAULT 'member',
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

JSON and semi-structured data

User preferences, feature flags, webhook payloads, form builder schemas. Store them in jsonb columns with full indexing and query support.

sql
ALTER TABLE users ADD COLUMN preferences JSONB DEFAULT '{}';

UPDATE users
SET preferences = '{"theme": "dark", "notifications": {"email": true, "slack": false}}'
WHERE id = 1;

SELECT email FROM users
WHERE preferences->'notifications'->>'email' = 'true';

You don't need MongoDB for this. PostgreSQL's jsonb is binary-stored, indexable, and queryable with a mature set of operators. For a SaaS where 95% of your data is relational and 5% is semi-structured, keeping it all in one database is simpler than running two.

Full-text search

Search help docs, user-generated content, or product catalogs without a separate search engine.

sql
ALTER TABLE teams ADD COLUMN search_vector TSVECTOR;
UPDATE teams SET search_vector = to_tsvector('english', name);
CREATE INDEX idx_team_search ON teams USING GIN (search_vector);

SELECT name, ts_rank(search_vector, query) AS rank
FROM teams, to_tsquery('english', 'acme') AS query
WHERE search_vector @@ query
ORDER BY rank DESC;

This won't match Meilisearch for typo tolerance, but for searching a few hundred thousand records in an admin panel or internal tool, it's more than enough with zero additional infrastructure.

Row-level security and partitioning

Multi-tenant SaaS? PostgreSQL has row-level security built in. Set a session variable per request and the database enforces tenant isolation. No middleware bugs, no forgotten WHERE clauses. When your events table hits tens of millions of rows, partition by date range and PostgreSQL automatically scans only relevant partitions. These are features you'd need a separate service or significant application code to replicate in other databases.

When to Add Redis

PostgreSQL handles persistent, relational, query-heavy workloads. Redis handles ephemeral, fast, structure-heavy workloads. They complement each other well, and Redis is usually the second database a SaaS adds.

Caching. Cache expensive query results, rendered templates, or API responses. Set a TTL and forget about it. SET user:123:dashboard <json> EX 300 gives you a 5-minute cache in one command.

Session storage. If you need server-side sessions (not JWTs), Redis is the standard. Fast reads, built-in TTL, and you don't pollute your PostgreSQL database with ephemeral session data.

Rate limiting. Sliding window rate limiting with sorted sets is 5 lines of Redis commands. Doing the same in PostgreSQL requires timestamps, cleanup jobs, and careful locking.

Background job queues. BullMQ, Bee-Queue, and other Node.js job queues use Redis as their backing store. Push jobs onto a queue, process them in workers, retry on failure. Redis handles the queue mechanics.

When to add it: Not on day one. Add Redis when you have a specific performance problem that Redis solves. "My dashboard query takes 3 seconds" is a reason to add Redis caching. "I might need caching someday" is not.

Spin up Redis alongside your PostgreSQL instance with SpinDB:

bash
spindb create saas-cache -e redis --start
spindb url saas-cache

Now you have both. See Getting Started with Redis for a full walkthrough with TypeScript.

When to Add a Search Engine

PostgreSQL's full-text search works well for internal tools, admin panels, and moderate-scale product search. You'll know when you've outgrown it because users will tell you: "search doesn't work" usually means one of two things.

Typo tolerance. Users type "kuberntes" and expect to find "kubernetes." PostgreSQL's pg_trgm extension handles fuzzy matching to a degree, but dedicated search engines like Meilisearch are built for this. Meilisearch gives you typo-tolerant, instant search with minimal configuration. If your product has a user-facing search bar, Meilisearch is the upgrade path.

Semantic search. Users type "comfortable running shoes" and expect to find products tagged "athletic footwear." This is a different problem entirely. The words don't match, but the meaning does. Qdrant handles this with vector embeddings. Convert text to vectors, store them in Qdrant, and query by meaning rather than keywords.

When to add it: When users complain about search quality. Not before. PostgreSQL's built-in search handles most early-stage SaaS search requirements. When it's no longer enough, read Full-Text Search vs Vector Search to figure out which kind of search engine you actually need.

Both run locally with SpinDB:

bash
spindb create saas-search -e meilisearch --start
# or
spindb create saas-vectors -e qdrant --start

The "I'm Special" Trap

Every SaaS team eventually has the conversation: "our data model is special, maybe we need a different kind of database." In my experience, that conversation is almost always premature. Here are the common ones.

"We need flexible schemas, so we need MongoDB"

No, you need jsonb columns. MongoDB's strength is document storage, but PostgreSQL's jsonb gives you the same flexibility inside a relational database. You keep foreign keys, joins, and transactions for the 90% of your data that's relational, and use jsonb for the 10% that's flexible. Running MongoDB as your primary database for a SaaS means giving up relational integrity for schema flexibility you could have gotten from a single column type.

If your entire data model is truly document-oriented with no relationships between entities, MongoDB makes sense. That's rare in SaaS. Users belong to teams. Teams have subscriptions. Subscriptions have invoices. That's relational data.

"We have hierarchical data, so we need a graph database"

PostgreSQL's ltree extension handles tree structures (org charts, category trees, permission hierarchies) with indexed path queries. Recursive CTEs handle arbitrary graph traversals. These cover the vast majority of "hierarchical data" use cases in SaaS applications.

Graph databases like Neo4j exist for a reason: complex, many-to-many relationship traversals across millions of nodes with variable-depth paths. That's social networks, recommendation engines, fraud detection. It's not your SaaS org chart.

"We have time-series data, so we need InfluxDB"

PostgreSQL with partitioning handles time-series data for most SaaS use cases. Partition your events table by month, add appropriate indexes, and you can query millions of time-stamped rows efficiently. The TimescaleDB extension adds automatic partitioning, compression, and continuous aggregates if you need them, and it runs inside PostgreSQL.

You need a dedicated time-series database when you're ingesting millions of data points per second from IoT sensors or infrastructure monitoring. Your SaaS analytics dashboard that tracks user events is not that.

The pattern

The pattern is always the same: a specialized database solves a specialized problem better than PostgreSQL. But your SaaS MVP doesn't have specialized problems. It has users, teams, subscriptions, and some JSON. PostgreSQL handles all of it. Add specialized databases when you have specialized problems, not when you imagine you might have them someday.

The Stack

Here's what I recommend for a SaaS MVP, in the order you should add them.

Day one: PostgreSQL. Handles your relational data, JSON data, basic search, and more. This is your source of truth for everything.

bash
spindb create saas-db --start
spindb url saas-db

When you need caching or job queues: add Redis.

bash
spindb create saas-cache -e redis --start
spindb url saas-cache

When users complain about search: add Meilisearch or Qdrant.

bash
spindb create saas-search -e meilisearch --start
# or
spindb create saas-vectors -e qdrant --start

That's it. Three databases maximum, added incrementally as your product demands them. Most SaaS products run on just PostgreSQL and Redis for years.

When you're ready for managed hosting, all of these engines are available on Layerbase Cloud.

Stop and start your local instances when you're not developing:

bash
spindb stop saas-db saas-cache
spindb start saas-db saas-cache

Further Reading

All databases run locally with SpinDB and are available as managed instances on Layerbase Cloud.

Something not working?