COMPUTE VIEWS HUB

Premium AI Tools • Hardware Marketplace • Procurement Insights

← Back to Overview
PUBLICATION TIMESTAMP
--

Three Engines, One Agentic Future: Kinetica, HeavyDB, and the SQream Aftermath

Three Engines, One Agentic Future: Kinetica, HeavyDB, and the SQream Aftermath

In a Hacker News thread burning bright in the spring of 2026, Todd Mostak—founder of HeavyDB—laid out a future he’s been chasing since before it was fashionable. “I believe within 2-3 years databases and data warehouses on GPU will be common,” he wrote. “The widespread use of agents to query data will be a part of this, as there will be a need to run far more queries at lower latency than needed for the ETL and BI workloads of the past.” The comment was a calm observation, not a marketing pitch. No one in the thread argued. By then, the evidence was piling up. Across the industry, AI agents are no longer passive SQL generators. They execute blocking, multi-step reasoning loops where the next move depends on the last result—sequentially, not in batch. A typical agent task can fire ten, twenty, fifty queries during a single conversation turn. At two seconds per query on a CPU-bound warehouse, the whole loop drags past the point of usefulness. Starburst and NVIDIA documented the economics bluntly: a 4.6× average GPU acceleration shrinks the wait time from 20 seconds to about 4 seconds for a ten-query chain. For production systems fielding hundreds of concurrent agent sessions, those 16 seconds of saved time per interaction are the difference between a responsive product and an embarrassing demo. That landscape has turned three GPU-native databases into objects of intense curiosity—and, in one case, a cautionary tale. Kinetica, HeavyDB (the open-source descendant of OmniSci/MapD), and SQream—briefly rebranded as Scailium before its bankruptcy—are each tackling the same problem from different architectural angles, and each carries a very different commercial weight in 2026. This comparison draws on internal documentation, academic benchmarks, real customer stories, and the unfiltered chatter of GitHub issues and Reddit threads to separate the engine that’s ready for agents from the one you should probably mourn and move past.

Before mapping the players, it’s worth understanding why the workload changed so abruptly. Traditional analytics workloads—dashboards, scheduled reports, occasional ad-hoc exploration—are relatively predictable. They tolerate cold starts. AI agents don’t. They generate high-frequency, high-concurrency, variable-shaped queries that often vector search, filter on tabular metadata, traverse a graph, and apply a geofence all within the same logical retrieval step. Stitching that together with five different specialty databases—vector store, RDBMS, graph DB, spatial engine, cache—creates real-world latencies no amount of query optimization can hide. Kinetica’s product team calls this the “3–5 hop” problem and claims their engine collapses it into a single GPU-accelerated query plan. Whether the claim holds under rigorous adversarial testing is still being debated in the community, but the principle aligns with what agent developers actually need: fewer round trips, more work per query, and fresh data ingested in real time. One Chinese tech architect at the 2026 WAIC conference framed the issue plainly: “AI agents bring high-frequency data access, causing traditional CPU architecture databases to gradually become a bottleneck. We moved the database to run on GPUs.” You don’t need a crystal ball to see where the industry is heading. The three companies in our crosshairs got there early. The question now is who built a product strong enough to survive the arrival of the moment.

Kinetica: The Converged Contender

Kinetica was founded in 2016 with a very particular ambition: replace the whole menagerie of specialty databases with one distributed, columnar, memory-first engine that runs vectorized operations across thousands of GPU cores. The architecture uses tiered storage—VRAM, RAM, disk, cold cloud buckets—and a chunk-level min/max metadata system for automatic skip-scanning. A single SELECT can run an ANN vector lookup, filter on relational predicates, traverse a graph, and apply a geofence on the same scan. Whether that’s always wise is another matter, but the capability exists. The company has been aggressive about positioning itself for the agent era. Its 2026 marketing material throws around phrases like “real-time AI and analytics” with the confidence of a startup that raised $77.4 million across seven rounds from Canvas Ventures, Meritech Capital, and Citi Ventures. Integration with NVIDIA NIM lets Kinetica compute embeddings at ingestion time—no nightly batch re-embeds—and the platform speaks MCP natively for tool-using agents and LangChain for orchestration. One recent commit to the LangChain integration patch was about error handling in querying, a tiny but telling sign that actual developers are kicking the tires. A concrete reference customer is Barghest Building Performance in Singapore. BBP uses Kinetica, backed by NVIDIA GPUs, to stream building sensor data, spot anomalies, and drive predictive maintenance that reportedly cut energy consumption by up to 40%. Meanwhile, GSK has used Kinetica to accelerate drug discovery workloads, and a telecom-focused “SQL-GPT for Telecom” demo shows where the company thinks the puck is going. These aren’t hypothetical wins—they’re live, often referenceable deployments. Kinetica’s pricing won’t be for everyone. The Developer Edition is free forever on a single node, but the fully managed dedicated cloud starts at $1.80 per hour, with enterprise contracts for self-managed clusters reportedly averaging around $548,600 annually. That’s real money, but it’s in line with enterprise database costs when the alternative includes a sprawling collection of tools and the headcount to maintain them. On benchmarks, Kinetica is not shy. Against ClickHouse 25.10 on identical 48-core, 384GB RAM boxes, Kinetica completed all 99 TPC-DS queries (ClickHouse managed 66% in single-node mode), ran 2.5× faster on shared queries, and showed positive scaling when moving from one to two nodes—ClickHouse’s distributed performance actually regressed. On the vector side, VectorDBBench shows Kinetica ingesting embeddings 5× faster than the previous leader. Those numbers come from Kinetica itself, mind you, but the patterns are directionally consistent with what NIM acceleration should deliver. Community feedback is harder to triangulate. PeerSpot gives Kinetica a 7.0 rating based on very few reviews; 100% of those who did respond said they’d recommend it. Gartner Peer Insights shows a 5-star rating from two reviews. The small sample size is common for specialized GPU databases, but it means you’re betting more on architecture and reference calls than on a rich tapestry of public user stories.

HeavyDB: The Open-Source Workhorse

HeavyDB—the descendant of Todd Mostak’s original MapD project and the OmniSci era—is the only one of the three that ships under Apache 2.0. That license is its superpower and its sustainability riddle. Any team can download the community edition, run it on a single node, and build proofs-of-concept without a vendor’s permission. When the project’s corporate parent (HEAVY.AI) goes through strategic shifts, the code remains. That’s more than a philosophical comfort in a year when one competitor went bankrupt. The architecture takes a hybrid CPU/GPU approach with JIT query compilation and multi-tiered caching. HeavyDB can run on NVIDIA GPUs, CPU-only x86, and experimentally on ARM—the latter demonstrated through a partnership with Vultr that uses GH200 Grace Hopper Superchip instances. The platform’s sweet spot has always been geospatial and time-series analytics on multi-billion row datasets without pre-aggregation or indexing. For agentic workloads, this flexibility means you could experiment on cheaper CPU instances and burst to GPU when latency matters, a pattern that existing cloud-heavy teams might appreciate. But academic scrutiny has been less forgiving. A 2024 University of Wisconsin-Madison study evaluated HeavyDB against BlazingSQL, Tensor Query Processor, and CPU-based DuckDB on TPC-H and SSB benchmarks. The results were jarring: DuckDB ran TPC-H Query 16 in 93 milliseconds; HeavyDB took 3,689 milliseconds. A more recent 2026 paper using the SHADB system claimed a 7.4× speedup over HeavyDB on SSB SF100. Those aren’t flattering numbers, and they stick to community memory. One GitHub issue documented GPU versus CPU sort inconsistencies that the team later resolved through “continuous improvement,” but the episodes color the narrative around production readiness for unpredictable agent queries. HeavyDB doesn’t have Kinetica’s unified multimodal retrieval story. Vector, SQL, graph, and spatial operations exist but aren’t elegantly fused into one query plan yet. The company’s answer to the agent challenge leans on HeavyIQ—an in-database LLM finetuned on over 60,000 instruction pairs, supporting text-to-SQL and summarization without external model calls. That’s attractive for air-gapped deployments where data leaves no footprint, but it’s a different kind of agent support: more about making humans faster than about slashing multi-hop agent latency. Pricing for the distributed enterprise edition is quote-based, with node-locked and floating license options introduced in version 8.0. The community edition is free and limited to single nodes. PeerSpot puts Heavy.AI at #42 in the SQL category with a 0.7% mindshare, just behind Kinetica at #37. The open-source community, scored by OpenSSF, shows limited but active maintenance—the latest commit landed on June 22, 2026. The pyheavydb Python package has nearly 3,000 stars, not trivial but not roaring. If you’re an engineering team that values code access above all, HeavyDB might be the bet you’re willing to make, with the clear caveat that complex query performance can jump off a cliff if you’re not careful.

SQream: The Bankruptcy Elephant

It’s impossible to talk about SQream in the present tense without acknowledging the bankruptcy. The Israel-based company, founded in 2010, had built a patented GPU acceleration engine capable of querying petabyte-scale data directly from cloud storage in open formats like Parquet and JSON. It claimed 10 patents around abstract data types and GPU-CPU co-processing, and it counted LG Uplus, PubMatic, and Cellcom among its customers. By late 2025, it had accumulated over $100 million in losses and roughly $4.7 million in unpaid debts. In January 2026, it rebranded to Scailium with talk of building an “AI production layer.” By May, it was filing for bankruptcy in Tel Aviv. The technology was real. Oracle had partnered with SQream to leverage its GPU acceleration, and customers like Thailand’s AIS reported shrinking insight time from days to seconds. But a Glassdoor profile compiled during the unraveling tells a human story: “Two massive rounds of layoffs within three months, both surprising.” No acquisition of those 10 patents has been publicly announced, and existing customers are now quietly mapping migration paths, possibly toward Kinetica, HeavyDB, or CPU-first options like DuckDB augmented with NVIDIA Sirius. For any reader considering a new deployment, SQream is effectively off the table. The core lesson is about vendor risk. GPU-native databases are still a young category. Even technically impressive engineering can’t outrun the financial gravity of a niche market that hasn’t yet crossed into mass adoption. When the market report numbers paint a picture of a sector growing at 11–22% CAGR and heading toward a $1.5–4.3 billion range by 2032, it’s easy to forget that individual companies can still implode. SQream’s bankruptcy is both a warning shot and a market-shaping event: it removes a competitor, concentrates attention on the survivors, and forces enterprises to scrutinize commercial stability more than ever.

[SPONSORED]

COMFYUI WORKFLOW OPTIMIZATION

Reduce render times by 40% with our automated edge-silicon pipelines. Download Whitepaper.

Where They Stand for AI Agents

Kinetica is the only one of the three treating AI agents as the primary design target. The architecture was built to eliminate the multi-hop retrieval pattern that drowns agent loops. Its tight coupling with NVIDIA NIM and its claim of in-database embedding generation mean that as an agent retrieves, the vectors are fresh—no drift between what the operational system knows and what the model sees. Dedicated product pages, LangChain patches, and referenceable customer wins in building performance and pharma make it the most commercially credible option today, albeit with a price tag that will give smaller teams pause. HeavyDB occupies the open-source high ground. It’s the rational choice if your organization insists on code control, or if you’re prototyping and want to avoid signing enterprise contracts for an experimental agent project. HeavyIQ adds a local LLM capability that could serve human-in-the-loop agent workflows, but the absence of a unified multimodal query plan and the uneven benchmark performance make it less compelling for latency-critical autonomous agents. The community is small but committed, and its hybrid CPU/GPU flexibility is genuinely useful when you don’t know whether your agent workload will actually need the GPU boost. SQream’s ghost is a reminder that the best technical pitch doesn’t guarantee survival. Its petabyte-scale query ability was impressive, but the market for that use case proved too narrow to sustain the burn rate. Anyone evaluating GPU databases in 2026 should treat commercial viability as a first-class requirement—not just a footnote in the procurement checklist.

Decision Cheat Sheet

Factor Kinetica HeavyDB SQream
AI Agent Focus Primary use case, multimodal engine Emerging, heavy reliance on HeavyIQ Announced, now frozen
Open Source No Apache 2.0 No
Unified Multimodal Vector + SQL + Graph + Spatial in one query Siloed capabilities Limited
Real-Time Streaming Kafka/CDC queryable on landing Limited via socket ingestion Batch-oriented
Complex Query Performance Strong on TPC-DS, vector benchmark Variable; DuckDB beat HeavyDB on TPC-H Q16 Petabyte-scale but unverified independently
Pricing Model Free dev tier, dedicated cloud from $1.80/hr, enterprise ~$548K/yr Free community (single node), enterprise quote-based N/A now
Commercial Stability Growing mindshare, active fundraising Open-source safety net, smaller company Bankrupt, out of business
None of these engines is a universal solution. Kinetica imposes a commercial lock that some teams will reject outright. HeavyDB asks you to accept engineering risk and live with a limited community. What’s different in 2026 is that the problem they solve is no longer a niche. Agent-driven querying is changing the database demand curve faster than most CPU-optimized warehouses can respond. The Starburst-NVIDIA integration, DuckDB with GPU backends like Sirius, and new entrants like Stinger with its GPU-native cognitive database all suggest that the real competition isn’t among these three—it’s between GPU-native architectures and the incumbent CPU world that is rapidly being stretched past its elastic limit.
Todd Mostak’s Hacker News comment was modest, but it contained a quiet edge. When you read it alongside the financial wreckage of SQream and the accelerating adoption of Kinetica in production agent pipelines, the real question isn’t whether GPU databases will become common. The question is which ones will still be standing when the agents finally do their work.
Editorial Disclosure: This commercial analysis is compiled from global informational platforms and developer community discussions. Due to rapid technical cycles, readers are advised to independently verify volatile metrics. COMPUTE VIEWS HUB maintains structural objectivity and independent neutrality. more
This publication is intended solely for commercial, educational, and informational purposes. Articles may include news reporting, editorial opinions, technical analysis, software tutorials, deployment guidance, benchmark testing, hardware evaluations, workflow optimization strategies, pricing references, market intelligence, developer resources, and enterprise technology commentary. Product specifications, APIs, licensing models, cloud pricing, benchmark results, software capabilities, commercial terms, and hardware availability are subject to change without notice. Any performance figures or comparisons are based on publicly available information, vendor documentation, independent testing, or specific test environments and should not be interpreted as universally representative. Readers are encouraged to verify all technical and commercial information directly with official vendors before making engineering, purchasing, investment, or operational decisions. Unless explicitly labeled as sponsored content, advertising, affiliate content, or paid partnerships, editorial decisions remain independent. COMPUTE VIEWS HUB does not warrant the completeness, accuracy, or future availability of third-party products, services, software, or information referenced within this publication.