Oleander

Oleander is a managed data warehouse that sits on open table formats and routes every query to whichever compute engine can answer it fastest and most cheaply. The site calls it a multi-engine data warehouse for agents and builders, and both halves of that phrase carry weight. It's pitched at teams who want warehouse capability without hiring a data platform group, and at AI agents that need to query real business data without a human translating every request into SQL first. The promise on setup is a fully managed warehouse running in under five minutes, with no cluster sizing, no catalog wiring, and nobody on call for it.

The problem it goes after shows up around the time a company's data outgrows a single database. You end up paying distributed-engine prices for queries a laptop could have run, because the warehouse you picked has exactly one way to execute anything and that way was sized for the worst case. Oleander's router looks at the characteristics of each query, a context graph of your data, and your historical cost patterns, then sends the work to the engine that actually fits, balancing cost, latency, and concurrency instead of forcing every workload down the same pipe. Cost history feeding back into routing is the part that compounds, since the system gets better at placing your workloads the longer it watches them.

The engine list is genuinely plural. Storage runs on Managed Iceberg, or you can point it at a Snowflake Horizon Catalog, an AWS Glue Data Catalog, or any Iceberg REST catalog you already operate. On the compute side there's Bloom, their own adaptive fully managed engine for lightweight execution, alongside DuckDB for single-node work, Polars for both single-node and distributed jobs, Spark for heavy distributed processing, and external Snowflake and Databricks for teams whose contracts and data already live there. A small aggregation can land on DuckDB while a large transformation goes to Spark, and the query you wrote doesn't change to make that happen. Building on Iceberg rather than a proprietary format also means the tables stay readable by whatever else you point at them.

The agent side is where it diverges most from a conventional warehouse. There are native plugins for Claude and Codex so an agent can query business data directly, plus a universal MCP server for anything else that speaks the protocol. Because letting a model run arbitrary SQL against production is how accidents happen, guardrails block destructive queries, and permissions can be scoped per user and per agent rather than handing one shared service account the keys to everything. There's also remediation tooling that investigates anomalies on its own and produces a root cause analysis instead of just firing an alert into a channel nobody reads. Queries can arrive as SQL or as natural language, which is the interface an agent will reach for anyway.

Governance and observability are on from the start rather than bolted on once something breaks. Lineage runs on OpenLineage and covers queries, datasets, and transformations, SQL telemetry gets captured from the very first query, and sensitive data can be governed through that same lineage graph so you can see where a given column actually travels through your stack. Environments stay separated across engines, which is what makes it reasonable to let an agent read one slice of the warehouse without quietly exposing the rest of it. For anyone who has tried to answer an auditor's question about where a customer field ended up, having that graph populated automatically is worth more than the feature list suggests.

You can reach the warehouse through a CLI that handles both queries and infrastructure, an SDK for code, plain SQL, or MCP when an agent is the one asking. The zero-ops framing is aimed squarely at teams with nobody to spare for platform work, and that's also the honest read on who should look at this. If you already run a mature Spark platform staffed by people who tune it, the routing layer solves a problem you've solved and the value drops sharply. If you have data, agents, and no dedicated data engineer, it's solving the problem you actually have, and the multi-engine routing is doing the job you'd otherwise be doing by hand every time cloud spend spiked.

Pricing is freemium with a real free tier rather than a countdown. Hobby is $0 and described as free forever, Pro is $300 a month or $3,000 billed annually, and Pro++ is $1,800 a month or $18,000 annually, with an Enterprise tier on a custom annual contract. Storage bills separately at $0.0276 per GB per month, and Spark compute is metered per second at $0.0000175 per vCPU and $0.0000019 per GB of RAM, so the plan fee isn't the whole bill and you'll want to model usage before committing to a year. There's a startups program and a demo booking link for anyone who needs a conversation before jumping from free to $300 a month.