What is the right database for my app?

The wrong database will not kill your app on launch day. It will kill it eighteen months later, when your engineers tell you the system needs a full rewrite and six figures of budget to fix a decision nobody questioned in week one.

Database choice is the most consequential technical decision most founders never think about. A 2020 Percona survey found that 38% of companies had migrated or were planning to migrate their primary database within two years. Not because the original database broke. Because it was the wrong fit from the start, and the cost of working around that mismatch kept compounding. The difference between picking the right database and the wrong one is not performance on day one. It is whether your engineering budget goes toward building features or fighting your own infrastructure.

Relational databases store data in organized tables, like a spreadsheet. Each row is a record, each column is a field, and the relationships between tables are defined up front. If you have customers and orders, a relational database forces you to define exactly how those two things connect before you store a single record. PostgreSQL, MySQL, and Microsoft SQL Server are all relational.

Non-relational databases (sometimes called NoSQL) store data more flexibly, without rigid table structures. MongoDB, the most popular NoSQL database, stores data as documents that look like nested folders. Each document can have a different structure. One customer record might have three phone numbers and another might have none, and the database does not care.

The tradeoff is straightforward. Relational databases enforce consistency. Every record follows the same rules, so your data stays clean and predictable. Non-relational databases offer flexibility. You can change the shape of your data without rewriting your entire storage structure.

DB-Engines tracked over 350 database systems as of late 2021. But the top five (Oracle, MySQL, Microsoft SQL Server, PostgreSQL, MongoDB) accounted for roughly 70% of all usage. Most founders do not need to evaluate 350 options. They need to understand two categories and pick one.

PostgreSQL is the safe default for almost every startup. Stack Overflow's 2021 Developer Survey showed PostgreSQL as the most-wanted database for the second year running, with 44% of developers wanting to use it. It handles transactions (think: payments, inventory updates, anything where two things need to happen together or not at all) better than any open-source alternative. It is free. Every cloud provider offers managed hosting. And you will never struggle to find a developer who knows it.

Pick MongoDB when your data genuinely has no fixed shape. A content management system where every article type has different fields. A product catalog where each category has unique attributes (shoes have sizes, laptops have RAM, paintings have dimensions). An event logging system that ingests data from dozens of different sources, each sending a different format. MongoDB handles these cases without forcing you to redesign your storage every time a new data shape appears.

A common mistake: picking MongoDB because it feels easier to start with. It is easier to start with. You throw data in and it works. But six months later, when you need to generate a report that joins customer data with order data with product data, you find yourself writing complex application code that a relational database would have handled with a single query. MongoDB Atlas reported 29,000 customers by mid-2021, and plenty of them started on MongoDB when PostgreSQL would have served them better.

Before picking a database, sketch your data on paper. Not code, not a diagram tool. Paper. Draw the main things your app tracks (users, products, orders, messages) and draw lines between them showing how they relate.

If you end up with lots of lines between boxes, and most boxes look the same (same columns, same structure), you want a relational database. Your data is interconnected and consistent. PostgreSQL will manage those connections for you automatically, and your developers spend their time on features instead of data management.

If your sketch has boxes with very different shapes, few connections between them, and you keep wanting to add "well, sometimes it also has this field," you want a document database like MongoDB. Your data is varied and evolving, and forcing it into rigid tables will create more problems than it solves.

A 2019 survey by ScaleGrid found that 40.4% of developers using MongoDB also used a relational database alongside it. That number tells you something: even teams that chose MongoDB often needed relational structure for part of their data. The inverse was less common. Teams running PostgreSQL rarely needed to bolt on MongoDB because PostgreSQL added native JSON support back in 2012, letting it handle semi-structured data reasonably well.

Here is a question that cuts through the noise: "Would a spreadsheet work for this data?" If yes, use a relational database. If you find yourself wanting to nest spreadsheets inside spreadsheets, consider a document database.

Graph databases and time-series databases solve specific problems that general-purpose databases handle poorly. They are not replacements for PostgreSQL or MongoDB. They are supplements.

A graph database (Neo4j is the most established) stores data as nodes and relationships. Think of a social network: people are nodes, friendships are relationships. Finding "friends of friends who also like hiking" is trivially simple in a graph database and painfully slow in a relational one. Neo4j had around 800 enterprise customers by 2021 and a thriving open-source community. But unless your core product revolves around relationship traversal (social networks, recommendation engines, fraud detection networks), you do not need one.

A time-series database (InfluxDB, TimescaleDB) is optimized for data stamped with a time. Server monitoring, stock prices, IoT sensor readings, user activity logs. The data arrives in chronological order and you almost always query it by time range ("show me the last 24 hours"). InfluxDB reported processing over 1.6 trillion data points per day across its cloud platform in 2021. PostgreSQL can handle time-series data, but a dedicated time-series database will query it 10-100x faster at scale because it stores and indexes data differently.

Most startups need exactly one database: PostgreSQL. Some need two (PostgreSQL plus Redis for speed). Very few need three. If someone tells you that you need a graph database, a time-series database, a document store, and a cache before you have your first paying customer, find a different advisor.

The honest answer: database choice barely matters at small scale. PostgreSQL, MongoDB, MySQL, they all handle 10,000 users without breaking a sweat. The differences show up at 100,000 users, become painful at a million, and become architectural at ten million.

PostgreSQL scales vertically well (bigger server, more performance) and horizontally with effort. Citus Data, acquired by Microsoft in 2019, showed PostgreSQL handling billions of rows across distributed clusters. For most startups, a single well-configured PostgreSQL instance on AWS RDS handles 50,000-100,000 concurrent users before you need to think about scaling strategies.

MongoDB was built for horizontal scaling from the start. It splits data across multiple servers automatically (a process called sharding, which in plain English means "spreading the load across more machines when one is not enough"). If you know your data will grow to terabytes and you need to spread it across dozens of servers, MongoDB makes that easier than PostgreSQL does.

But here is the part that rarely gets discussed: most performance problems have nothing to do with which database you picked. A 2020 Datadog analysis of thousands of production databases found that 80% of slow queries were caused by missing indexes (think of an index like a book's table of contents, without it the database reads every single page to find what you need). Fix the indexes and performance jumps 10-50x. That works on any database.

The pattern Timespade sees repeatedly: a founder spends weeks agonizing over PostgreSQL vs MongoDB, then ships the app with neither properly configured. The database choice mattered less than the setup. A well-configured PostgreSQL instance outperforms a poorly configured MongoDB cluster every time, and vice versa.

Yes, and many production apps do. The pattern is called polyglot persistence, which is a fancy way of saying "use different databases for different jobs." Netflix uses around eight different data storage systems. Uber uses more than a dozen. You are not Netflix or Uber, but the principle applies at every scale.

A common combination for startups: PostgreSQL as the primary database (users, orders, core business data), Redis as a cache (storing frequently accessed data in memory so it loads instantly instead of hitting the main database every time), and maybe Elasticsearch for full-text search if your product has a search bar that needs to feel instant.

Redis, an in-memory data store, reported over 43% usage among developers in the 2021 RedisLabs survey. Most of those developers were not using Redis as their primary database. They were using it alongside PostgreSQL or MongoDB to speed up specific operations. Storing a user's shopping cart in Redis means the cart loads in under 5 milliseconds. Storing it in PostgreSQL means 50-100 milliseconds. Users do not consciously notice the difference, but their behavior changes: Amazon found that every 100ms of latency cost 1% in sales (Greg Linden, 2006).

The risk of polyglot persistence is complexity. Two databases means two systems to monitor, two backup strategies, two potential failure points. Three databases means three of each. For a startup with two engineers, that overhead can eat a meaningful chunk of their time.

Timespade's recommendation for most startups: start with PostgreSQL only. Add Redis when you have a specific speed bottleneck you can measure. Add a specialized database (Elasticsearch, a graph database, a time-series store) only when PostgreSQL is measurably failing at a specific task. Every database you add should solve a problem you already have, not a problem you imagine having.

Managed database hosting means a cloud provider handles the server, backups, security patches, and uptime for you. You just use the database. AWS RDS, Google Cloud SQL, Azure Database, MongoDB Atlas, and PlanetScale are all managed options. For a startup without a dedicated operations team, managed hosting is not optional. It is mandatory. Running your own database server is like maintaining your own electrical grid when you could just plug into the wall.

Pricing varies by provider, but the ranges are predictable.

A 2021 Percona survey found that 60% of database workloads were running in the cloud, up from 48% in 2020. The shift happened because managed hosting eliminates the need for a full-time database administrator (who costs $120,000-$160,000/year in the US according to Glassdoor 2021 data). For a startup, $200/month for managed hosting versus $13,000/month for a DBA is not even a decision.

Where founders get surprised: data transfer costs. AWS charges $0.09 per GB for data leaving its network. If your app serves 10 million API requests per month, each returning 50KB of data, that is about 500 GB of transfer and $45/month in bandwidth fees alone. These costs are small individually but add up. Budget 20-30% on top of your base hosting cost for transfer, storage overages, and backup retention.

A traditional consultancy charges $15,000-$25,000 to set up a production database with backups, monitoring, and security hardening. Timespade does the same work for $4,000-$6,000 because the engineering team has done it dozens of times and has standardized templates for every major cloud provider. Same result: automated backups, encrypted connections, monitoring dashboards, and a database that does not keep you up at night. The difference is that Timespade's team lives in a part of the world where senior engineers earn $25,000-$40,000/year instead of $160,000, and that cost difference flows directly to you.

PostgreSQL with a managed host. Not close.

PostgreSQL has the best documentation of any open-source database. It has been around since 1996 (technically its predecessor Ingres started in 1973, making the lineage nearly fifty years old). Every web framework in every programming language has a PostgreSQL connector. Every tutorial on the internet assumes PostgreSQL or MySQL. Every question you will ever have has already been answered on Stack Overflow.

MongoDB is a close second for ease of getting started. MongoDB Atlas offers a free tier (512 MB storage) that handles a small product without costing a dime. The initial learning curve is lower because you do not need to define your data structure up front. But that flexibility becomes a liability if you are the only developer, because nobody is enforcing data consistency except you, and you will forget.

Stack Overflow's 2021 survey showed PostgreSQL used by 40.4% of professional developers, up from 36.1% in 2020. MySQL was at 50.2% but trending down. MongoDB held at 27.7%. The trend matters because a larger community means better tooling, more Stack Overflow answers, and easier hiring when you eventually bring on your first engineer.

Ignore the noise about specialized databases. CockroachDB, Neo4j, DynamoDB: they each solve real problems, but probably not yours, and not yet. Start with PostgreSQL because it does 90% of what every app needs, the remaining 10% can wait, and you will never paint yourself into a corner.

Timespade has set up databases for solo founders and for teams with forty engineers. The advice is the same either way: pick PostgreSQL, use a managed host, and do not optimize for problems you do not have yet. When a solo founder asks Timespade to set up their data layer, the deliverable is a configured PostgreSQL instance with automated backups, connection pooling (so the database handles many users without choking), and a monitoring dashboard. That setup takes a day and costs $800-$1,200. The same work from a US-based consultancy runs $3,000-$5,000 because their hourly rate reflects San Francisco office rent, not the complexity of the work.

Painful enough that you should make the right choice now, but not so painful that a wrong choice is permanent.

Switching from one relational database to another (PostgreSQL to MySQL, or vice versa) is relatively straightforward. The data structures are similar, the query languages are 90% identical, and migration tools handle most of the conversion automatically. A 2020 Datastax survey found that organizations spent an average of 12 months on database migrations, but relational-to-relational migrations were the fastest, often completing in 2-4 months.

Switching from relational to non-relational (PostgreSQL to MongoDB) or vice versa is a different story. You are not just moving data. You are changing how your application thinks about data. Every query, every data access pattern, every assumption your code makes about how information is stored needs to change. It is the software equivalent of converting a building from residential to commercial: the foundation might be the same, but everything built on top of it needs rework.

The cost of a database migration depends on the size of your application.

The hidden cost of migration is not the migration itself. It is the feature freeze. While your engineers are moving data and rewriting queries, they are not building the features your customers are asking for. A six-month migration means six months of your product standing still while competitors ship. That opportunity cost dwarfs the dollar cost of the migration work.

One practical hedge: build a data access layer. Instead of having every part of your application talk directly to the database, put a thin layer of code in between. If you later switch databases, you rewrite the access layer instead of rewriting your entire application. Timespade builds this into every project by default. It adds about a day of development time up front and saves months if a migration ever becomes necessary.

The bottom line: pick PostgreSQL for most apps. Pick MongoDB for genuinely schema-less data. Use managed hosting. Do not add specialized databases until you have a measurable problem that your primary database cannot solve. And if you are unsure, ask someone who has set up hundreds of production databases instead of guessing. Timespade offers free architecture consultations for exactly this reason. The call takes 30 minutes and costs nothing. Schedule one here.