How to Choose a Database for Your App: Why We Start With PostgreSQL

For most new apps, start with one PostgreSQL database. It handles what nearly every product stores, from users and orders to payments and permissions, and it keeps flexible JSON data next to them when you don’t yet know its shape. Add a second store only when you can name the job it does better, such as Redis for caching and background jobs, or a store built for a flood of events. The bigger risks sit elsewhere: a data model nobody checked, and backups nobody has tried to restore.

Why PostgreSQL is our default

PostgreSQL is a relational database. It keeps related records consistent with transactions: a payment and the order it pays for are saved together, or neither is saved. For anything involving money, stock or bookings, that is the property you want.

It also stores JSON well. The PostgreSQL docs say the jsonb type supports indexing and that most applications should prefer it for JSON data. In practice, you can keep a settings object or an imported payload in a JSON column and still search it, without adding a second database for “flexible” data.

And people know it. In the 2026 Stack Overflow Developer Survey, 57.9% of all respondents had done extensive work in PostgreSQL over the past year, more than any other database in the list. SQLite came second at 42.1% and MySQL third at 35.1%. Every major cloud sells a managed version, so you don’t have to run the server yourself.

We use PostgreSQL across our own projects: in Subflare for app data, in Ginger Snail with Redis next to it, and through Supabase in Daisy’s Guide, where a small team got a Postgres database with sign-in and Stripe payments built in.

SQL or NoSQL is the wrong first question

Older guides, including the first version of this article, framed the choice as SQL against NoSQL. The more useful question is this: does your data have relationships and rules that must always hold?

If a customer has many orders, an order has many items and a refund must point to a real payment, you want a relational database. If each record lives on its own, like an event from a website visitor or a reading from a device, a document or key-value store can be simpler and cheaper at volume.

The line has blurred. MongoDB, a widely used document database, supports multi-document ACID transactions. Its own docs still say transactions cost more than single-document writes, and that for many cases embedding related data in one document remains the better design. So the shape of your data should decide.

Which store for which job

Job	Good fit	Where we used it
Users, orders, payments, permissions	PostgreSQL (or MySQL)	Subflare app data, Ginger Snail
Caching and background job queues	Redis	Subflare (Redis with BullMQ for background jobs), Ginger Snail
A high-volume stream of events	A store built for that load	Subflare (DynamoDB for visitor events)
A backup copy that takes load off the main database	A second, independent store	Sigmapool (MongoDB next to PostgreSQL)
A small team that doesn’t want to run servers	Managed Postgres with sign-in built in	Daisy’s Guide (Supabase)

Each row is one job. When a store doesn’t have a clear job, it is one more thing to back up, secure and pay for.

Redis is the usual second store: 28.3% of respondents in the same 2026 survey had worked extensively with it. Check its licence before you build on it. Since Redis 8, released in May 2025, the open source AGPLv3 licence is one of the options (Redis announcement), and managed services may run Redis or a fork of it. Ask your provider which one you get.

Subflare: one job per store, decided before launch

Subflare scores B2B leads by what a visitor did on a website before filling in a form. Early drafts used Supabase Auth and MongoDB. During the build the architecture changed on purpose: AWS Cognito for sign-in, PostgreSQL for app data, DynamoDB for the stream of visitor events and Redis with BullMQ for background jobs. All of the data sits on AWS in Europe. The Subflare case study covers the rest.

The timing is what made it cheap. Changing stores in a draft touches code only. Changing them after launch means migrating live data while customers use the product.

Sigmapool: protect the main database’s main job

Sigmapool, a crypto mining pool we built, keeps PostgreSQL for mining data only. Next to it, MongoDB works as an independent database that backs up essential data and takes load off the main one. The platform also keeps an active backup instance, so it can reset to a saved version in an emergency. The pool reports 99.9% uptime. Details are in the Sigmapool case study.

Three jobs to keep out of the main tables

Files such as photos, PDFs and uploads belong in object storage, like Amazon S3. The database keeps only each file’s address and details. Large files inside database rows make backups slow and restores slower.

Search can start inside PostgreSQL, which has built-in full-text search. Move to a separate search engine when you need typo tolerance, custom ranking or volumes that slow down the main database.

Reports and analytics run long queries that compete with your users for the same database. Once those reports start to slow the app, copy the data to a separate reporting database and run them there.

Get the data model right before the features

The database engine matters less than the tables inside it. On Koncierge, a payment platform for Japan, the team summed up the core of the product as the data, the data structure and the API structure. We checked the business domain before writing any feature, because a wrong data model would break every dashboard, settlement and withdrawal built on top of it. Records are never erased there, so the history of every payment stays complete. More in the Koncierge case study.

What to check before you commit

• Which data must never be wrong? Money, stock and bookings belong in tables with transactions.
• Are backups automatic, with point-in-time recovery? On Amazon RDS, for example, transaction logs go to S3 every five minutes and you can restore to any moment within the retention period.
• Has anyone restored a backup? On RDS a restore creates a new database instance, so practice the switch before launch.
• Whose cloud account is it? IPOPBOOKS, Koncierge and HealthyNikah run on the client’s own AWS account.
• Which major version will you run, and until when does it get fixes? The PostgreSQL project supports each major version for 5 years. Version 13 stopped getting fixes in November 2025, and version 14 gets its last release on 12 November 2026. Version 18, out since September 2025, is supported until November 2030.
• Where does the data live? If your customers are in the EU, decide the region early. Subflare keeps everything in Europe.
• Who can read production data? During the IPOPBOOKS build, only one person at Rocketech could see client data.
• Do schema changes go through migration files and code review, or does someone edit the live database by hand?

What we would do

1. Write down the 5 to 10 things your app stores and how they relate to each other.
2. Start with one managed PostgreSQL database in your own cloud account.
3. Use jsonb columns for data whose shape you don’t know yet.
4. Add Redis once you need caching or background jobs.
5. Add any other store only when a measured load or a specific feature needs it, and give it one job.
6. Turn on automatic backups with point-in-time recovery, and restore one before launch.
7. Keep every schema change in a migration file that someone reviews.

If you want this done as part of a first release, see our web app development page. A first version typically costs $5,000 to $15,000 with us and takes 2 to 4 weeks. To see what your idea costs to build, run it through our project estimate: it turns your brief into user stories, and every hour in the budget traces back to a story you kept, priced at our published $39-55 an hour.

FAQ

Should my app use SQL or NoSQL?

Start from your data. If records relate to each other and rules must always hold, as with orders, payments and permissions, use a relational database such as PostgreSQL. If each record stands alone and arrives in large volumes, such as visitor events, a document or key-value store can fit that one job.

Is PostgreSQL or MySQL better?

Both are mature relational databases. We default to PostgreSQL for its JSON support and because it is the most used database in the 2026 Stack Overflow survey, at 57.9% of respondents. Choose MySQL if your team or your hosting already runs it.

When do I need Redis?

When you need a fast cache, or a queue for background jobs such as sending emails or processing uploads. In Subflare, Redis with BullMQ runs the background jobs. Redis usually sits next to your main database and doesn’t replace it.

Can I change the database later?

Yes, but it gets more expensive once you have live users and live data. Subflare changed its stores during the build, before launch, when it cost the least. Plan the data model and the stores before the first release.