Choosing a Database for a Small SaaS: Why It Is Usually Postgres

Of all the early technical decisions, the database is the one you will live with longest. Interface code can be rewritten in a few weeks. The data, its shape, and the system that holds it tend to persist for the life of the product, and moving them is slow, risky, and visible to customers if it goes wrong.

That is why this decision deserves more thought than most, and also why the answer for most small products is more boring than people expect. The interesting options exist, and they are rarely what a young product needs.

Start from what you actually need

The right database depends on how the data behaves, not on what is fashionable. A few questions cut through most of it.

Is the data structured, with clear relationships between things, such as customers, orders, and invoices? Do you need to query it in ways you cannot fully predict yet? Does it need to stay consistent, so that a payment and the record of it either both happen or neither does? How much data and traffic do you realistically expect in the next two years, not in a hoped-for future?

For most business software the answers are: structured, relational, queried in many ways, consistency matters, and modest scale. That profile points firmly at one kind of database.

The relational default

A mainstream relational database, with PostgreSQL the most common choice, handles this profile extremely well. It enforces structure so bad data is rejected at the door. It supports transactions, so related changes happen together or not at all. It lets you ask questions you did not plan for, using standard queries. It has decades of tooling, documentation, hosting options, and people who know it.

It also scales much further than people assume. A single well-configured instance serves many thousands of customers for most business applications. Before reaching for something more exotic, it is worth asking whether the problem is the database or the queries running against it.

Modern relational databases also handle semi-structured data reasonably, so a few flexible fields do not require abandoning the relational model.

Where SQLite fits

SQLite is a database in a single file, with no separate server. It is far more capable than its reputation suggests, and for the right products it is simpler, faster, and cheaper than running a database service.

It suits single-user tools, local applications, prototypes, and some small products with modest, mostly-read traffic. It removes a whole component to operate. The case for it overlaps with local-first software: when one person runs a tool on one machine, a hosted database is a cost without a benefit.

Its limits show up with many simultaneous writers and when several servers need to share one database. At that point, moving to a client-server database is the natural step, and starting with relational discipline makes that move manageable.

When a different kind of database earns its place

Other types exist for good reasons. Document databases can suit data that truly varies in shape from record to record. Key-value stores and caches are excellent for fast lookups and temporary data. Search engines handle text relevance better than a general database. Analytical stores handle large aggregate queries over history. Time-series and graph databases fit their respective shapes.

The mistake is choosing one of these as the primary store for ordinary business data because it sounds modern. They are specialised tools, usually best added alongside a relational core when a specific need appears, not instead of it. A flexible schema feels liberating at first and becomes costly when you need to enforce rules and report across records.

Design the schema like it will last

Whichever database you pick, the schema matters more. Model the real entities and their relationships carefully, use proper types and constraints, and name things clearly. A good schema makes queries natural and prevents whole classes of bugs; a sloppy one spreads its problems through every feature built on it.

If the product will serve more than one customer, include tenancy in the schema from the start, as laid out in multi-tenant SaaS architecture. It is among the hardest things to add later. The same applies to anything involving money, where an append-only record of events, as in payments and billing architecture, saves a great deal of pain.

Plan for change

Schemas evolve. Use migrations: versioned, repeatable scripts that change the database structure, kept in source control and applied the same way in every environment. Make changes in small, reversible steps, and prefer additive changes, adding a column before removing an old one, so the code and database can be updated separately without downtime. The same careful staging described in migrating off legacy software applies on a smaller scale.

Do not neglect the operational basics

A database is not finished when it works. It needs backups that are tested by actually restoring them, monitoring so you notice slow queries and growing storage before they bite, and a plan for recovery. Managed database services remove much of this burden and are usually worth the cost for a small team. Choosing one is part of the boring-technology argument in choosing a tech stack for an MVP.

Index and measure before you scale

Most early performance problems come from missing indexes and inefficient queries, not from the database being too small. Measure which queries are slow, add indexes where they help, and look at the query plan before concluding that you need a bigger or different system. Scaling up a single database, adding read replicas, and caching hot data come well before redesigning the architecture.

A short decision guide

For a single-user or local tool, SQLite is likely enough. For a multi-user product handling business data, start with PostgreSQL on a managed service. Add specialised stores only when a concrete need appears that the relational database serves poorly. And whatever you choose, invest in the schema, the migrations, and the backups.

We design the data layer products grow on. See how we work on applications, or read about technical debt triage.