Overview
Soda provides software that lets data teams define checks on their data, run automated tests, and alert on quality issues across warehouses, lakes, and pipelines. Its open-source CLI tool and SaaS platform serve data engineers and analysts who need visibility into whether their data is trustworthy.
The company raised EUR 11.5M in 2021, a further EUR 11.5M in 2022, and EUR 14M in 2024. It has publicly stated reaching financial self-sufficiency, a notable milestone in a period when many SaaS companies remained dependent on ongoing venture support.
Soda operates in the data observability space alongside companies like Monte Carlo and Great Expectations, and is relevant to any Belgian enterprise data stack conversation.
Funding & milestones
2 events found for Soda · 2021–2024
Series AVenture / equity1 source€11.5M
Reported amount €11,500,000
Company release announces €11.5m Series A; €14m is total funding including the earlier seed, not this round.
Series a extensionVenture / equity2 sources$14M
Reported amount $14,000,000
Contemporaneous reporting describes $14m as an extension of Soda’s Series A financing.
InvestorsSingularPoint Nine Capital
Recorded history so far. Original currencies are preserved; amounts in different currencies are not added together. Debt, grants, acquisitions and listings are separate event types. Undated events appear last.
Profile narrative
- EUR 11.5M2021
- EUR 11.5M2022
- EUR 14M2024
Key people
In the news
- A data product isn’t ready for use if its quality checks are still waiting in someone’s backlog. Those checks are part of delivering the product. If consumers start using the data before the agreed requirements are tested, they’re relying on expectations the team hasn’t verified. That’s why quality needs to be part of the 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻 𝗼𝗳 𝗱𝗼𝗻𝗲. → First, the team building the product agrees with its consumers on what the data must satisfy, using shared data standards as a starting point. → Then it turns those
- Adding a check after every data quality incident is useful. It isn’t a complete strategy for finding the next one. Your coverage also needs a way to surface problems nobody has thought to write a check for. After an incident, your team investigates what went wrong and adds a check to catch that condition next time. That’s progress. Each failure teaches you something worth testing. Business requirements and shared data standards help you go further, defining what the data must satisfy before anything breaks. But whether a check comes
- Data quality is solved. We're showing how on November 17. When companies invest in data quality, their goal is clear: find issues, understand why they happen, and fix them at the source. Historically, these three goals have not been easy to achieve. That changes today. Expanding data quality coverage shouldn’t require a proportional increase in manual work. -Writing checks for every new table. -Tracing failures back to their source. -Correcting affected records. Automating the work gives teams more capacity to define
- What is a silent data failure? The job succeeds. No error appears. The report loads on time. But the number in it is wrong. A silent data failure happens when incorrect data passes through without triggering an error or alert. Two examples: ➨ A missing amount is replaced with zero, making “unknown” look like a measured value. ➨ An incorrect time-zone conversion assigns late-night sales to the wrong reporting day. The people using the data shouldn’t have to be the first ones to discover it’s wrong. Catching these failures has to be
- Is handing data quality rules to domain teams the same as giving up control? Only if control means writing every rule yourself. Rules also belong with the teams that know what correct means for the data they use: - Sales ops knows what a valid deal looks like. - Finance knows when a revenue number is off. - Marketing knows what counts as a qualified lead. The trouble starts when each team keeps its rules somewhere different: a spreadsheet, a pipeline step, a quality tab in the warehouse. Then governance can't tell which rules exist,
- The data quality rules that governance can read don't run. The data quality checks that run, governance can't read. Take an orders table. Rule A: "Customer ID is required." It sits in the business's spreadsheet. Governance can read it. It runs only when someone opens the file. Rule B: "amount must be above 0." It runs on every load. It lives inside a pipeline governance never sees. So no single place answers your real question: Which rules run on orders, and did they pass on the last load? Governance and engineering both need to
- If the file holding your data quality rules failed tomorrow, how long would it take you to find the one rule that caused it? For most governance teams, the rules already exist. A data steward knew the business well enough to write all of them. That's real work. Then it all goes into one SQL query. It might execute fine. It just can't be governed. You can version the file. Not each rule. You can't hand ownership of specific rules to the team that owns the data. One query holding every rule you own has a blast radius the size of
- What would it take for you to hand a data management job to an AI agent? On Thursday, October 8, element22 and Soda are hosting a closed working session in New York on that question. Here's how the afternoon works: ➨ A 30-minute primer on how an AI agent is built, using Soda's own agents as examples ➨ An hour at tables of five, designing one data management agent on paper ➨ Each table presents, and everyone receives a written comparison afterwards When: Thursday, October 8, 3:30 to 6:00 PM, then a reception and dinner Where:
Related profiles
Something wrong or missing? Send an update. Fixed within 24 hours.