The database is the one part of an application you will almost never replace. Screens get redesigned and code gets rewritten, but the data and its structure tend to outlive everything else. So it is worth choosing well.
I recommend one of two databases: PostgreSQL or MongoDB. Both are mature, widely used, available as fully managed services on Google Cloud, and they keep your data in a form you can export and move. The question is which one fits your data.
The short version#
| If your data looks like… | Choose |
|---|---|
| Customers, orders, invoices, bookings, stock levels | PostgreSQL |
| Product catalogs where every category has different attributes | MongoDB |
| Content, articles, form submissions, event logs | MongoDB |
| Anything involving money that must always add up | PostgreSQL |
| Not sure yet | PostgreSQL |
PostgreSQL: when the relationships matter#
PostgreSQL stores data in tables with defined columns, and it is very good at relationships: a customer has many orders, an order has many lines, each line points to a product.
Its main strength for a business is that it enforces the rules itself. You can tell the database that every order must belong to a real customer, that a quantity can never be negative, or that an invoice number is unique. Even if the application has a bug, the database refuses to store nonsense. Transactions make sure that related changes, such as taking payment and reducing stock, either all happen or none do.
It is also the best choice for reporting. Questions like “revenue by region by month for customers who ordered twice” are a few lines of SQL, a language that analysts and many reporting tools already speak.
On Google Cloud it runs as Cloud SQL, with automated backups, patching and failover handled for you.
MongoDB: when the shape keeps changing#
MongoDB stores documents, which are flexible records that look like the JSON your web application already works with. Two documents in the same collection do not need the same fields.
That flexibility shines when the data does not fit neatly in a table:
- A catalog where shoes have sizes, laptops have memory and services have durations
- Form submissions whose questions change every season
- Content and settings that evolve as the business experiments
Adding a field does not need a migration, and reading a whole record, such as a product with all its variants, is a single fast lookup.
On Google Cloud it is available fully managed through MongoDB Atlas.
The questions that actually decide it#
- Will you need reports across many related things? Lean PostgreSQL.
- Is accuracy critical, for example money, stock or bookings? Lean PostgreSQL.
- Does every item have a different set of attributes? Lean MongoDB.
- Is the data mostly read and written as whole documents? Lean MongoDB.
- Is the data currently in spreadsheets with consistent columns? That is already a table, so lean PostgreSQL.
It is also fine to use both: PostgreSQL for the transactions and MongoDB for a flexible catalog or content store. For most small businesses, though, one database is simpler to run and cheaper to host, and simplicity is worth a lot.
What matters more than the choice#
Whichever database you choose, three things matter more than the brand:
- A data model designed around how you work, not around a template
- Automated backups that have actually been restored in a test
- Open formats, so that you can always export your data and take it elsewhere
Get those right and either database will serve you well for years.
Planning a new application or moving out of spreadsheets? Let’s talk about your data.