--- title: Why ad platforms run six databases to answer one question description: Ad platforms accumulate six or more databases not by design but through incremental decisions: a key-value store for auction lookups, a columnar store for... canonical: https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why ad platforms run six databases to answer one question | daily.dev og:description: Ad platforms accumulate six or more databases not by design but through incremental decisions: a key-value store for auction lookups, a columnar store for... og:url: https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3 og:image: https://api.daily.dev/og/posts/9dEw0UPB3.png og:image:alt: Why ad platforms run six databases to answer one question og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why ad platforms run six databases to answer one question **[SingleStore](https://daily.dev/sources/singlestore)** · 11 min read · 1 upvotes · 0 comments ## Summary Ad platforms accumulate six or more databases not by design but through incremental decisions: a key-value store for auction lookups, a columnar store for real-time aggregates, a search index for audience filtering, caches, and eventually a vector store. Each addition is locally rational but collectively creates a lambda-style architecture with duplicate data, pipeline latency of 40+ minutes, reconciliation overhead, and fragmented ownership. The core problem is that warehouses and lakehouses handle batch OLAP well but cannot serve the low-latency, high-concurrency HTAP workloads ad platforms require. HTAP engines that store data in both row and columnar formats can ingest streams and make them immediately queryable, eliminating the need for most secondary systems. The recommended approach is incremental migration starting with the highest-friction workloads, while keeping the warehouse for historical archives and model training. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do ad tech platforms end up running so many different databases? Ad platforms accumulate separate systems because each workload demands something warehouses and lakehouses cannot deliver at low latency: a key-value store handles millisecond auction feature lookups, a columnar store serves near-real-time pacing dashboards, a search index filters audiences across many attributes, and a vector database handles similarity search. Each addition duplicates the same event, and reconciling those copies becomes a permanent engineering burden. _For teams weighing consolidation versus more point stores, daily.dev surfaces engineering perspectives on serving-layer architecture._ ### What is HTAP and how does it reduce database sprawl in real-time systems? HTAP (hybrid transactional/analytical processing), a category Gartner established in 2014, lets high-speed writes and analytical reads run against the same data in a single engine by storing data in both row and columnar formats. This lets one system ingest streams directly and make them queryable immediately, eliminating the secondary key-value stores, columnar stores, and search indexes that a fragmented architecture requires. _Engineers evaluating whether HTAP fits their stack can track this architectural shift on daily.dev._ ### Should you replace your data warehouse when adopting a real-time serving layer? No, a serving layer augments the warehouse or lakehouse rather than replacing it. Petabytes of historical archives and intensive model training still belong in the lakehouse, while the serving layer takes over hot, concurrent, latency-sensitive customer-facing work such as auction lookups and advertiser dashboards that warehouses were never built to handle. _Teams planning a phased migration off legacy warehouses can follow this architecture debate on daily.dev._ ## Similar posts on daily.dev - [Why Real-Time and AI Break the Classic Data Stack](https://daily.dev/posts/why-real-time-and-ai-break-the-classic-data-stack-hnpharhri) · SingleStore · 0 upvotes · 0 comments - [Why Traditional Data Warehouses Can’t Handle Hi-Tech Workloads](https://daily.dev/posts/why-traditional-data-warehouses-can-t-handle-hi-tech-workloads-b1ypyo1dc) · SingleStore · 0 upvotes · 0 comments - [From monolith to Lakebase to LTAP: rethinking the database from storage up](https://daily.dev/posts/from-monolith-to-lakebase-to-ltap-rethinking-the-database-from-storage-up-gsup5t8nr) · databricks · 6 upvotes · 0 comments - [What Is HTAP? Hybrid Transactional Analytical Processing Explained](https://daily.dev/posts/what-is-htap-hybrid-transactional-analytical-processing-explained-1acrd3d2i) · CrateDB · 0 upvotes · 0 comments - [Databricks pitches LTAP as a new foundation for agentic applications](https://daily.dev/posts/databricks-pitches-ltap-as-a-new-foundation-for-agentic-applications-eiwc37ccu) · InfoWorld · 0 upvotes · 0 comments --- Tags: [#data-architecture](https://daily.dev/tags/data-architecture), [#singlestore](https://daily.dev/tags/singlestore) [View this post on daily.dev](https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why ad platforms run six databases to answer one question","url":"https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3"},"datePublished":"2026-07-09T14:04:23.900Z","dateModified":"2026-09-14T06:37:08.313Z","description":"Ad platforms accumulate six or more databases not by design but through incremental decisions: a key-value store for auction lookups, a columnar store for...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b686130899f002e54d5b45184ad6cc64?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b686130899f002e54d5b45184ad6cc64?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"SingleStore","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"SingleStore","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/e2118b72d715435c84d6060bbe11d275","url":"https://daily.dev/sources/singlestore"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"data-architecture,singlestore","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"SingleStore","item":"https://daily.dev/sources/singlestore"},{"@type":"ListItem","position":3,"name":"Why ad platforms run six databases to answer one question"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/why-ad-platforms-run-six-databases-to-answer-one-question-9dew0upb3#faq","mainEntity":[{"@type":"Question","name":"Why do ad tech platforms end up running so many different databases?","acceptedAnswer":{"@type":"Answer","text":"Ad platforms accumulate separate systems because each workload demands something warehouses and lakehouses cannot deliver at low latency: a key-value store handles millisecond auction feature lookups, a columnar store serves near-real-time pacing dashboards, a search index filters audiences across many attributes, and a vector database handles similarity search. Each addition duplicates the same event, and reconciling those copies becomes a permanent engineering burden. For teams weighing consolidation versus more point stores, daily.dev surfaces engineering perspectives on serving-layer architecture."}},{"@type":"Question","name":"What is HTAP and how does it reduce database sprawl in real-time systems?","acceptedAnswer":{"@type":"Answer","text":"HTAP (hybrid transactional/analytical processing), a category Gartner established in 2014, lets high-speed writes and analytical reads run against the same data in a single engine by storing data in both row and columnar formats. This lets one system ingest streams directly and make them queryable immediately, eliminating the secondary key-value stores, columnar stores, and search indexes that a fragmented architecture requires. Engineers evaluating whether HTAP fits their stack can track this architectural shift on daily.dev."}},{"@type":"Question","name":"Should you replace your data warehouse when adopting a real-time serving layer?","acceptedAnswer":{"@type":"Answer","text":"No, a serving layer augments the warehouse or lakehouse rather than replacing it. Petabytes of historical archives and intensive model training still belong in the lakehouse, while the serving layer takes over hot, concurrent, latency-sensitive customer-facing work such as auction lookups and advertiser dashboards that warehouses were never built to handle. Teams planning a phased migration off legacy warehouses can follow this architecture debate on daily.dev."}}]} ```