--- title: What database technology is best for my apps data needs description: Choose the right database by understanding data structure, read and write patterns, scale needs and the true cost of switching technology later. image: https://weareaffective.com/hubfs/learning-centre-images/what-database-technology-is-best-for-my-apps-data-needs.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-database-technology-is-best-for-my-apps-data-needs#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What database technology is best for my apps data needs Table of Contents The database decision sits at the centre of every product build, and engineers routinely treat it as a technical formality rather than a product decision. They pick what they know, or what the framework suggests, and move on. That works until it doesn't, and by the time it stops working, the cost of changing course is significant. According to [Security Boulevard, 2023](https://securityboulevard.com/2023/03/choosing-the-right-database-for-your-mobile-app-7-emerging-mobile-app-databases/), 77% of mobile app developers consider the database the most critical component of their app, yet the decision rarely gets the time it deserves at the start of a project. > The database decision is a product decision, not just a technical formality. The right database for your app depends on a cluster of things that are specific to your product: how your data relates to itself, how often it gets read versus written, how many users you expect and when, and where your product sits in its lifecycle. There is no universal answer. There is only the answer that fits your actual situation. What follows is how we think through that decision on the products we build, drawing on the patterns we have seen work and the ones that have caused problems. The aim is to give you a clear framework for making a choice you will not regret twelve months later. ## Relational vs Non-Relational: What the Distinction Actually Means in Practice The relational versus non-relational debate is the first thing most people encounter when researching databases, and it is also the first place confusion sets in. The distinction matters, but not in the abstract way it is usually taught. #### Relational databases: structured and connected A relational database stores data in tables. Rows and columns, with defined relationships between them. If you have users, orders, and products, each lives in its own table and they connect via foreign keys. PostgreSQL and MySQL are the most widely used examples. The [Stack Overflow Developer Survey 2023](https://survey.stackoverflow.co/2023) found PostgreSQL used by around 46% of respondents and MySQL by around 41%, making them by some distance the most common choices in production. The structure enforces consistency, which is valuable when your data has clear, predictable relationships that do not change much over time. #### Non-relational databases: flexible and document-based A non-relational database, often called NoSQL, stores data in a different shape entirely. Documents, key-value pairs, graphs, or time-series records, depending on the type. Firebase Firestore, MongoDB, and DynamoDB are common examples. The flexibility is real: you can store different shapes of data in the same collection without defining a rigid schema first. That makes iteration fast, particularly in early product stages where your [data model is still evolving](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). The trade-off is that complex queries across related data become harder, and consistency guarantees are weaker. Neither is better in the abstract. The question is which fits what your data actually does. ## How Your Data's Structure Should Drive the Decision Before choosing a database technology, the most useful thing you can do is draw out your data model. Not in code, just on paper. What are the main entities, how do they relate to each other, and how deeply nested does that structure get? If your data is naturally tabular and relational, users who have orders, orders that contain products, products that belong to categories, a relational database fits that shape well. The joins are what you want. The schema enforces the relationships so that data integrity is maintained without extra application logic. If your data is hierarchical or variable in shape, a survey response that contains a dynamic set of question answers, or a conversation thread that contains messages with different metadata depending on message type, a document-based store fits more naturally. You can nest data inside a single document and retrieve it in one read, rather than joining across multiple tables. Sketch your data model before you open a database comparison page. If you find yourself drawing tables with lines between them, lean relational. If you find yourself drawing nested boxes, lean document-based. The practical danger is picking the database and then bending the data model to fit it. That produces data structures that feel awkward and queries that fight the storage format. Start from the data, then match the technology to it. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Read and Write Patterns: The Question Most Builders Skip How your app reads and writes data has a bigger effect on database performance than almost any other factor, and it is the question teams most often skip during the selection process. Some apps are read-heavy. A product catalogue, a content library, a reporting dashboard: users retrieve data far more often than they create or update it. Others are write-heavy. A real-time logging tool, a survey response system, a messaging product: data is being written constantly, and reads happen in bursts. An app can be both, but with different patterns in different parts of the product. > The read and write pattern of your app shapes every database performance decision you will make. On a real-time messaging product we worked on, we used Firebase Firestore to store conversations and messages. The anonymous messaging feature required security rules that let users read messages without identifying the sender. We initially saw performance slowdowns and assumed the cause was in the application code. After investigation, we found the issue was in the database layer: the security permission checks were running inefficiently against the way messages were stored. Adding extra indexes and reworking the storage structure resolved it. The write pattern had shaped how permissions were evaluated on read, and until we understood that connection, we were looking in the wrong place. The point is that read and write patterns affect speed, how you structure security, how you index your data, and how complex your queries become. Mapping those patterns before you choose your database saves significant rework later. ## Scale Is Not Just About Volume Scale is the word teams reach for when they imagine future success, and it tends to mean "lots of users". But scale is more specific than that, and treating it as a single variable leads to poor database decisions. There are at least three distinct dimensions worth separating out. - Volume: how many records you are storing and retrieving - Concurrency: how many users are hitting the database at the same time - Velocity: how fast data is being written, and whether that happens in steady streams or sudden spikes A wellness app with 50,000 users who each log data once a day has a very different scale profile from a social app with 10,000 users who are all active at the same time. The first has high volume and low concurrency. The second has moderate volume and high concurrency. The database choice that handles one well does not automatically handle the other well. Relational databases handle concurrency with transactions and locking, which is reliable but adds overhead. Document-based databases like Firestore scale horizontally more naturally, which suits high-concurrency scenarios where you can accept eventual consistency. Neither is the right default: the right answer depends on which dimension of scale your product actually faces. Before making a database decision based on expected scale, separate volume, concurrency, and velocity. They often point to different solutions, and conflating them leads to over-engineering in the wrong direction. ## When a Lean Database Choice Is the Right One There is a strong case for reaching for the simplest database solution that your product genuinely needs, particularly at the proof-of-concept or MVP stage. The danger is confusing "simple" with "limited". A lean choice is deliberate and appropriate, not a compromise made from ignorance. On the performance coaching survey app we built, we used Firebase's real-time database as the backend for the MVP rather than building a traditional API. Each survey a presenter created generated a record in Firebase. Audience members accessed their own unique response record via keys embedded in the QR code URL. This allowed real-time response logging with tight security, restricting each user to reading and writing only their own response record, and kept the build lean and appropriate for a proof of concept. That choice was right for that stage. Firebase handled the real-time requirements, the security model was achievable without a full API layer, and the speed of build was appropriate for validating the concept. The key phrase there is "for that stage". A lean database choice is a product decision, not just a cost decision. It is only correct if it genuinely fits the current requirements and does not create structural problems that make the next stage harder. The question to ask is not "can we get away with this?" but "does this match where the product actually is?" Those are different questions, and the first one tends to produce regret. ## The Hidden Cost of Skipping an API Layer Going direct from client to database, as we did on the performance coaching survey app, is an attractive option in early stages. It removes a layer of complexity, speeds up the build, and reduces infrastructure costs. But skipping a traditional API layer introduces a security challenge that demands serious attention. The biggest technical challenge on the performance coaching survey app was locking down Firebase security rules without the protection of a dedicated API layer. We had to scrutinise every security rule carefully to ensure that neither the app nor the web response page could be exploited. With no API acting as a controlled intermediary between the client and the database, the [security rules had to do all the work](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) that an API layer would normally handle. That is achievable, but it requires significantly more care than a setup where the API controls what queries can even be formed. An API layer does more than route requests. It validates inputs, enforces business logic, controls what data shapes can be read or written, and provides a consistent surface for authentication. When you remove it, all of that responsibility moves into the database security rules, the client code, or both. That is not necessarily wrong, but it is a conscious trade-off, not a simplification. If you are going direct to database without an API layer, map every possible read and write path the client can make, then ask what happens if a bad actor follows each one. Security rules need to cover all of them, not just the happy paths. ## How Storage Structure Affects Query Performance The way data is physically stored inside a database has a direct effect on how quickly queries can run. This is true for both relational and document-based systems, but it shows up differently in each. In relational databases, indexes allow the database engine to locate rows without scanning the entire table. Without them, a query on a large table is slow regardless of how well written the SQL is. The index adds a small overhead to writes but dramatically speeds up reads on the indexed columns. The trade-off is deliberate: you pay a small write cost to get a fast read cost on predictable query patterns. In document-based databases like Firestore, the indexing model is different. Firestore automatically indexes every field by default, which helps simple queries but can cause problems when security rules need to run across complex data structures. On the messaging product we worked on, the performance issue we encountered was precisely this: the security permission checks were running against a data structure that made them expensive. Reworking how messages were stored, so that the fields the security rules needed to check were easier to reach, brought the performance back to where it should have been. The storage structure and the query pattern need to be designed together, not independently. ## Cold-Start Latency and the Serverless Trade-Off Serverless databases and functions introduce a specific performance characteristic that matters a great deal for some products and almost nothing for others: cold-start latency. When a serverless function has not been called recently, it needs to spin up before it can respond. That delay ranges from roughly 100 milliseconds to a few seconds depending on runtime and package size, according to [Triazine Soft](https://triazinesoft.com/blog/what-is-serverless-architecture-a-complete-guide-for-enterprises). For a product with consistent traffic, the functions stay warm and the latency disappears. For a product with sparse or irregular usage, every gap in traffic can produce a cold start. We worked on a holistic mental health and wellness product covering mental health, eating habits, exercise, and general wellness. We evaluated serverless architecture early in the project but ruled it out because the endpoint usage pattern would have been too inconsistent. Without a steady stream of requests hitting the same endpoints, cold-start latency would have been unacceptably high for users. We ultimately built a monolithic service with message queues and a small number of separate services, which worked much more effectively for that product's usage profile. We have also experienced cold-start lag on [social media applications built on serverless architectures](https://weareaffective.com/learning-centre/how-do-you-design-social-hooks-that-keep-users-coming-back-daily). In those cases, the lag was only present at the very start, before a regular user base was established. Once traffic became consistent, the latency dissipated. The difference between that and the wellness product is traffic pattern: [social apps tend to generate dense, regular usage](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) across a broad user base, which naturally keeps functions warm. A niche wellness product with varied check-in habits does not, and that makes serverless the wrong fit regardless of its other advantages. ## Why Switching Databases Later Is So Expensive Changing your database after a product is in production is one of the most expensive technical decisions a team can face. The real cost is everything the database assumption has baked into the rest of the codebase, on top of the migration itself. Query patterns, data models, security rules, caching strategies, and API contracts all form around the database you chose at the start. When you switch, you are not swapping one component for another. You are unpicking a thread that runs through almost every layer of the product. The application code that constructs queries, the API layer that shapes responses, the tests that verify behaviour: all of it was written against assumptions that no longer hold. Technical debt, left unaddressed, does not stay still. On a long-running communications product we worked on, [deferred debt remediation was repeatedly pushed back](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) until the accumulated fragility of the product forced a larger and more disruptive intervention than would have been needed at any earlier point. The same dynamic applies to database choices. A database that is wrong for the product does not become more tolerable over time. It becomes more entangled, and the cost of fixing it grows with every release built on top of it. The most practical protection against this is making a conscious, considered choice at the start. Not a permanent one, because no choice is permanent, but a deliberate one with documented reasoning. When the decision needs revisiting, you know what trade-offs were made and why, and you can assess the new situation against that baseline rather than starting from scratch. ## Matching Database Technology to Where Your Product Actually Is The most common database mistake is choosing for the product you hope to have rather than the product you are actually building right now. That produces over-engineered systems at the start and under-prepared ones later, often at the same time. A useful way to think about it is in three broad stages. 1. Proof of concept or MVP: prioritise speed of build, flexibility, and cost. A document-based database or a lean real-time store like Firebase is often appropriate. The data model will change, so a rigid schema is a liability. 2. Early production: the data model is stabilising and query patterns are becoming clearer. This is the stage to assess whether the MVP database choice will hold at the next order of magnitude, and to introduce an API layer if one is missing. 3. Scaled product: performance, consistency, and operational overhead matter more. Relational databases earn their complexity at this stage. Indexing, query optimisation, and data integrity become daily concerns rather than occasional ones. The [Stack Overflow Developer Survey 2023](https://survey.stackoverflow.co/2023) found SQLite used by around 31% of developers, largely reflecting its role in mobile and local storage contexts where a lightweight, embedded database is the right fit. That is the same logic applied at a smaller scale: fit the tool to the actual context, not the theoretical one. What this requires is honesty about where the product actually is, and a willingness to revisit the database choice at each transition rather than treating the first decision as permanent. ## Conclusion Database decisions feel technical, but they are really product decisions expressed in technical terms. The right choice depends on your data's shape, your read and write patterns, your scale profile, your stage of development, and how much operational complexity your team can realistically carry. None of those factors stay fixed, which is why the decision deserves revisiting as the product grows rather than being made once and forgotten. The patterns we have described here come from building across a range of product types, from [real-time messaging and wellness platforms](https://weareaffective.com/learning-centre/problems-people-face-daily-that-need-simple-app-solutions) to survey tools and motion picture production management. What we have found, consistently, is that the teams who get this right are the ones who slow down at the start of a project to ask the [structural questions: what does our data actually look like](https://weareaffective.com/app-architecture-design-we-are-affective), how will it be accessed, and where are we in the product lifecycle? Those questions are not glamorous, but they prevent the kind of expensive rework that makes a product harder and slower to develop over time. A lean choice made deliberately is a good choice. A lean choice made because nobody asked the question is a liability waiting to surface. The same is true for every other decision in this article. The goal is deliberate rather than accidental, and revisable rather than irreversible. If you are working through a database decision and want a second perspective on the trade-offs, [let's talk about your product's data needs](https://weareaffective.com/get-started). ## Frequently Asked Questions Why is choosing a database considered a product decision rather than just a technical one? The database you choose shapes how your data is structured, how quickly your app can scale, and how costly it is to change direction later. Getting it wrong early on can create significant technical debt, which is why it deserves careful thought at the start of a project rather than being treated as a formality. What is the main difference between relational and non-relational databases? Relational databases store data in structured tables with defined relationships between them, enforcing consistency across your data. Non-relational databases use more flexible formats such as documents or key-value pairs, which makes them easier to adapt when your data model is still evolving. Which relational databases are most commonly used in production apps? PostgreSQL and MySQL are by far the most widely adopted, with the Stack Overflow Developer Survey 2023 finding that around 46% of developers use PostgreSQL and around 41% use MySQL. Both are well-supported, mature technologies with strong communities behind them. When should I consider using a NoSQL database over a relational one? NoSQL databases are a strong fit when your data model is still changing frequently, as they allow you to store different shapes of data without committing to a rigid schema upfront. Tools like Firebase Firestore, MongoDB, and DynamoDB are particularly useful in early product stages where flexibility matters more than strict consistency. How do I work out which database structure suits my app? A practical first step is to sketch out your data model on paper, mapping your main entities and how they relate to one another. If your data is naturally tabular and deeply relational, a relational database is likely the better fit. If your data is loosely connected or variable in shape, a document-based approach may serve you better. What are the trade-offs of using a non-relational database? The flexibility of NoSQL databases comes at a cost. Complex queries across related data become harder to write and maintain, and consistency guarantees tend to be weaker than those offered by relational databases. These trade-offs are manageable in the right context, but they need to be understood before committing to the approach. Is there a universally correct database choice for most apps? There is no single correct answer, as the right database depends on factors specific to your product, including your data relationships, expected user load, and where your product sits in its lifecycle. The goal is to find the option that fits your actual situation rather than defaulting to whatever is most familiar. What happens if I choose the wrong database early in a project? The immediate impact may be small, but the cost of switching databases once a product is in production can be very high, affecting data migration, application logic, and team time. This is why the decision is worth investing in properly at the outset, even if it feels like a detail in the early stages. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.