Kevin Mathrani is a Chief Software Architect at Amdocs Inc. specializing in large-scale cloud data platforms for telecommunications.gettyChoosing the right database technology for your extract, transform, load (ETL) pipeline workloads is a critical step at the start of any greenfield project or modernization initiative.A database shapes application performance, operating costs and how reliably data reaches business consumers. It is the backbone of your analytics and AI use cases, where reliable, timely data translates into higher revenue. The risk of getting the foundation wrong is rising: Gartner predicts that through 2026, organizations will abandon 60% of AI projects that aren't supported by AI-ready data.If the choice isn't made strategically, problems can surface a year later—leaving you weighing whether to migrate terabytes of data and redesign pipelines. In my work architecting enterprise data platforms, I’ve found that a few critical discussions are worth having before choosing a database.Know your data.The best platform choices start with a clear understanding of the data moving through your business. Three questions shape the choice, and each answer points toward a different technology—so getting them right early prevents expensive rework.The first is how the data behaves. Does it arrive continuously, or in large scheduled batches? Are you mostly adding records, or constantly changing existing ones? A steady stream of real-time changes points toward systems designed to react instantly, while large overnight batches point toward platforms built for bulk processing. These are priced and engineered very differently, so knowing which dominates rules out whole categories of tools and avoids paying for capabilities you'll never use.The second is how much data there is and how fast it's growing. A platform that is economical today can become a cost and performance liability once volumes multiply. Sizing for the growth curve, not just current load, makes a decision that lasts years, not months.The third is how the data will be used and by whom. Will people run broad analyses that scan large volumes, quick lookups of individual records or both? Because databases are tuned for particular usage patterns, this answer often decides the platform outright—the wrong match is felt by every user, every day, as slow reports and rising bills.Decide on a data warehouse versus NoSQL.ETL architectures commonly use an operational database to ingest and curate data before moving it to a data warehouse for analytics. Understanding why this split exists is key to deciding whether you need both.Operational databases—often NoSQL systems—excel at reacting to change instantly and fetching individual records with almost no delay, suiting situations where the business must act on new data in near real time. Data warehouses are built to scan massive volumes and perform the heavy summarization behind dashboards and reports. Each is excellent at its own job and weak at the other's.The strategic question is whether one platform can serve both needs, avoiding the cost of maintaining data in two systems. To judge that, an executive needs a clear read on their operations: How fresh does the data need to be—do decisions depend on data seconds old, or is daily fresh enough? How often do consumers look up a single record versus analyze data in bulk?Those answers expose the trade-off. If the business genuinely needs split-second freshness on individual records and heavy analytics, forcing both onto one platform can compromise performance and inflate costs—two specialized systems may be cheaper long term. But if real-time needs are modest, consolidating onto a single modern warehouse cuts spend and lowers maintenance. Warehouse vendors are rapidly closing this gap, so keep evaluating these features against your operational requirements.Design the right data model.How you organize data is often treated as a technical detail, but it is a business decision requiring business experts and product designers to work together. The data model determines how much storage you consume, how quickly people get answers and how much maintenance the system demands.The central trade-off: The way you arrange data to save space is not always the way you make answers fast. Traditional databases manage the connections between related data. Distributed systems built for scale usually don't, so your team must deliberately reorganize data around the questions people ask most—sometimes storing the same information in more than one place.Some platforms offer built-in features that make common lookups faster, but those shortcuts consume storage and slow how quickly new data is saved. The takeaway: Cutting storage costs is legitimate, but the real goal is lower complexity, faster answers and cheaper maintenance. Storage has grown far cheaper over the years, giving room to duplicate data in return for system speed and a better user experience.Know the limits, and plan for real-world conditions.Every database has limits that, if exceeded, may cause it to slow down or fail. What organizations really must solve is predictability and resilience: confidence that the platform will hold up under peak load—billing cycles, promotion-driven surges, a data backfill—without slow dashboards or an outage. The goal is to find those limits before your customers do.Vendors provide technical specifications, but they can't be taken as-is—every organization's data differs. The only reliable approach is testing under realistic conditions: running your actual pipelines against production-scale data to see where performance degrades.A key decision surfaces here: how much capacity to buy. Provision generously, and you get headroom but pay for resources you rarely use. Provision leaner, and you save money but risk slowdowns when demand spikes. A related option is pacing—slowing how fast pipelines feed data in so they never overwhelm the database. This protects stability but adds complexity, can delay data availability and may violate service level agreements (SLAs). There is no universally right answer. Choose deliberately, with real numbers, rather than discovering the limits in production.Finally, invest early in monitoring tools and rehearse failure scenarios—resilience is far cheaper to build in advance than to retrofit after an incident.ConclusionThese questions merely scratch the surface, but they convey the key considerations when selecting a database for ETL pipelines. With due diligence, you can choose wisely and avoid major issues down the road.​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?