An hour is an awkward unit of business intelligence. It is long enough to leave a meeting, make coffee, forget the original question and return with a different one. In a 2018 announcement, SQream reported that a complex speed-test query at Thailand’s mobile operator AIS had fallen from as much as an hour to less than 50 seconds. Hundreds of millions of records were involved. The interesting change was what people could ask next.
- The job: accelerate large SQL queries and data preparation using NVIDIA GPUs.
- The audience: enterprises whose analytics outgrow the time or money available.
- The useful distinction: familiar SQL over a different processing engine.
- The buying test: measure the complete workflow on your own data.
AIS needed to understand network quality across locations. SQream says its dashboard joined disparate records into a view managers could explore, using one server and one Tesla GPU. Its later case study describes the old inconvenience: data had to be aggregated before analysis. Decide what matters, reduce the evidence, then ask your question. That is a peculiar bargain for an organisation collecting ever more evidence.
The pitch that needed a translator
The business began with a communication problem. In his founding account, Ami Gal recalls meeting Kostya Varakin at Seedcamp in Tel Aviv in May 2010. Varakin presented an idea called Gpustream. Gal says the audience lost the thread, and he grasped little beyond the word GPU. A conversation afterward, followed by coffee, gave the idea a recognisable purpose: a database.
Gal assigned a technical task he thought would take three months. By his account, Varakin finished in three weeks. The company formed in 2010; Razi Shoshani is also identified as a co-founder. Today he is CTO. This origin has a useful lesson for anyone selling difficult technology: an ingenious engine becomes easier to explain when somebody names the work it will do.
Thousands of hands, one familiar language
SQreamDB is a columnar analytical SQL database. The columnar part matters: an analysis can read the fields it needs without hauling every field along. The GPU part lets suitable operations run across many processing cores. Joins, grouping and sorting feature in its technical documentation. A SQL compiler written in Haskell organises the work; C++ and CUDA workers execute it. There is considerable engineering behind that modest-looking query window.
Limited graphics-card memory is an obvious obstacle. SQream’s engineering writing describes dividing data into chunks to process datasets larger than GPU memory. Compression and metadata help it avoid reading unnecessary data. Its architecture separates storage from compute. The proposition is therefore more specific than putting a graphics card beside a database and hoping for applause.
Users retain SQL clients and familiar analytical tools through interfaces including JDBC, ODBC and Python. That reduces one kind of switching cost: people need not learn an entirely new language to investigate an entirely old business problem. SQreamDB can serve as a warehouse, a preparation engine or an analytical component within existing infrastructure.
When the workaround becomes the warning
In SQream’s NCBA banking case, fragmented Oracle analytics became difficult enough that analysts copied data onto laptops. Loading delays compounded the problem. The organisation evaluated an Oracle upgrade and Hadoop, then judged their investment requirements unjustified. SQream became an analytics complement; Oracle remained responsible for transactional banking.
The vendor reports reductions of up to 81% in loading, preparation and analytics time. It also describes SQream as three times less expensive than the alternatives considered. Treat that as a relative case-study claim, rather than a price list. The revealing choice was architectural: keep the transaction system, give heavy analysis another engine.
“SQream helps us to keep pace with rapidly increasing data usage”Suppachai Panichayunon, AIS
In SQream’s 2018 customer announcement
The database gets a larger assignment
SQream now puts its engine inside a broader AI story. Preparation, training and inference are the three stages on its homepage. AISQream promotes production-sized machine-learning datasets and NVIDIA RAPIDS workflows. The practical ambition is to reduce the preparation bottleneck before an expensive model-training run begins.
The portfolio also contains a quieter counterpoint. SQream acquired Panoply in December 2021, adding no-code integrations and automated cloud warehouse management. Its announcement said Panoply brought hundreds of customers. SQream still markets that product to small and medium businesses. An organisation may need less configuration long before it needs petabyte-scale processing.
Capital followed the expansion: $26.4 million in a 2018 Series B led by Alibaba Group, $39.4 million in a 2020 Series B+, and $45 million in a 2023 Series C led by World Trade Ventures. The last round targeted North American expansion and AI/ML capabilities. In April 2025, Liam Galin became CEO and Gal moved to chairman. The current website also points visitors toward SCAILIUM, an AI production layer.
Buy the answer, time the journey
SQream occupies the space between GPU analytics specialists such as Kinetica and the broader warehouse choices buyers evaluate, including Snowflake and Databricks. Its public pricing describes an annual subscription per GPU, with a quote from sales. Its user agreement also permits contracted monthly usage billing. Hardware, storage, integration and operational effort belong in the comparison alongside the software.
The hardware guide makes the trade-offs concrete. It recommends at least 256GB of system RAM per GPU and substantial storage throughput. Smaller GPU memory can limit concurrency. An analytical engine is also a poor automatic substitute for a transaction system requiring multiple statements inside one transaction: SQream’s architecture documentation specifies that limitation.
A buyer can copy a simple discipline from these cases. Select the query people keep postponing. Measure ingestion, preparation, execution and simultaneous users. Compare the complete bill. If storage is the bottleneck, or the dataset is modest and existing tools already answer promptly, more GPU compute may offer little. The prize is having enough time left to ask the second question.