Databend

Open-source enterprise data warehouse unifying analytics, vector search, full-text search, and AI agent orchestration in a single Rust-built engine on S3.

9.4Kstars
891forks
Custom / Unknown

Databend is an open-source cloud-native data warehouse rebuilt from scratch in Rust, purpose-built for enterprise AI workloads and large-scale analytics. It unifies SQL analytics, native vector search, full-text search, geospatial queries, and auto schema evolution in a single engine — without requiring separate specialized databases for each workload type.

What sets Databend apart for AI teams is its Sandbox UDF system: Python agent logic runs in isolated, resource-managed sandboxes orchestrated directly through SQL. This lets developers define LLM reasoning loops, tool-use chains, and multi-step agent workflows as standard SQL functions and run them at scale on production enterprise data, with transactions and Git-like data branching ensuring safe experimentation.

Databend is architecturally cloud-native, decoupling storage from compute and running natively on S3, Azure Blob Storage, or GCS. It speaks Snowflake-compatible SQL and ships native drivers for Python, Go, Java, Node.js, and Rust. The ecosystem includes integrations with BI tools like Metabase and Superset, ELT platforms like Airbyte and dbt, and AI frameworks including MindsDB and an MCP Server.

Deployment is flexible: start on Databend Cloud in seconds, run locally as a Python library using databend-driver, or self-host via Docker. The project is actively maintained with nightly releases, over 33,000 commits, and contributions from more than 200 developers.

What You Get

  • Python Sandbox UDFs for AI Agents - Define agent logic, LLM calls, and tool-use workflows as isolated Python functions that execute inside Databend’s managed sandbox environment and are invoked directly via SQL.
  • Native Vector Search - Store and query vector embeddings with cosine distance, L1, L2, and inner product functions built into the query engine — no external vector database required.
  • Full-Text Search - Run inverted-index full-text search alongside structured SQL queries in the same engine, enabling hybrid retrieval for RAG pipelines without additional services.
  • Git-like Data Branching - Create lightweight snapshots of production datasets for agents or ML experiments to operate on safely, then commit or discard changes without affecting live data.
  • Auto Schema Evolution - Tables automatically adapt to incoming data structure changes, removing brittle schema migration steps from ETL and streaming ingestion pipelines.
  • Snowflake-Compatible SQL - Full SQL dialect compatibility enables teams to migrate from Snowflake or existing cloud warehouses without rewriting query logic or BI tool configurations.
  • Multi-Modal Data Types - Native support for structured columns, semi-structured JSON (VARIANT type), vectors, geospatial types, and full-text in a single table schema.
  • Elastic Cloud-Native Architecture - Compute scales independently of storage; data persists on S3/Azure/GCS with no proprietary lock-in, and queries fan out across distributed worker nodes.

Common Use Cases

  • Building AI Agents on Enterprise Data - A platform team defines Python UDFs implementing LLM reasoning, web tool calls, and structured output parsing, then orchestrates them as SQL queries over millions of customer records to generate personalized recommendations at warehouse scale.
  • Hybrid Vector + SQL Search for RAG - A search engineer stores document embeddings alongside metadata in Databend, then retrieves the top-k semantically similar chunks using cosine distance functions filtered by SQL predicates — all in a single query for low-latency RAG pipelines.
  • Enterprise BI on a Data Lake - An analytics team connects Tableau or Metabase directly to Databend querying S3-backed Parquet files, leveraging auto-scaling compute and Snowflake-compatible SQL without ETL into a separate warehouse.
  • Safe Feature Engineering for ML Models - A machine learning team creates a data branch from production snapshots, runs experimental feature transformations and model inputs, validates results, and discards the branch — leaving live data untouched.
  • Multi-Source ELT at Scale - A data engineer configures Airbyte to stream data from operational databases into Databend, using dbt models for transformation and auto schema evolution to handle upstream schema drift without pipeline failures.
  • Geospatial and Multi-Modal Analytics - A logistics company runs spatial joins using ST_Hilbert and R-Tree indexes on geographic data, combining them with full-text search on driver notes and vector similarity on product embeddings in a single analytical query.

Under The Hood

Architecture Databend is organized as a large Rust workspace with distinct, independently versioned crates for the query engine, metadata service, common utilities, and enterprise extensions. The query engine follows a pipeline-based MPP (massively parallel processing) model inspired by ClickHouse’s processor architecture: computation is expressed as directed graphs of Processor trait objects connected through typed ports, where each processor emits events (NeedData, Sync, Async, Finished) to drive execution. This compositional model cleanly separates concerns between scheduling, execution, and data movement. The metadata service (databend-meta) is an independent distributed system with its own Raft-based consensus, typed KVAPI abstraction, and Protocol Buffer serialization — completely decoupled from the query layer. Storage is architecturally separated from compute, with logical metadata (snapshots, segments, columns) mapped to physical object storage keys through a versioned schema, enabling serverless scaling on any S3-compatible backend.

Tech Stack The entire core is written in Rust using the 2024 edition, built on Tokio for async execution with a custom TrackingGlobalAllocator for per-query memory accounting. Internal services communicate via gRPC with Protocol Buffer message types auto-generated from .proto definitions. The query planner and optimizer are implemented from scratch rather than building on Arrow DataFusion or other frameworks, giving the team full control over join ordering, runtime filter pushdown, and cost estimation. Vector distance functions (cosine, L1, L2, inner product) are implemented with ndarray for SIMD-friendly computation. Python agent sandboxes communicate with the query engine over Apache Arrow Flight. The toolchain enforces strict code quality with clippy, rustfmt, ruff for Python scripts, and custom lints that ban direct tokio::spawn calls in favor of the project’s managed runtime abstractions.

Code Quality The test suite is extensive: nearly a thousand SQL logic test files spanning unit queries, TPC-H, TPC-DS, and specialized suites for UDFs, EE features, compatibility checks, and geospatial functions. Rust unit tests cover core abstractions including pipeline processors, vector distance computations, and proto-conv serialization. Error handling is typed throughout, with a centralized ErrorCode enum and Result<T> propagation — there is no widespread use of .unwrap() in production paths. The CI pipeline runs linting, formatting, and multi-version compatibility tests on every commit, with nightly releases cut automatically after passing. Code organization follows consistent domain-bounded naming: crates, modules, and types are named by function (databend-common-pipeline-core, databend-query-functions) rather than by technical layer.

What Makes It Unique Databend’s most distinctive capability is collapsing workloads that traditionally require separate systems — a columnar warehouse, a vector database, a full-text search engine, and an agent execution environment — into a single SQL-addressable engine that stores everything on commodity object storage. The Sandbox UDF architecture is genuinely novel: rather than calling an external Python service, Databend manages a control plane for sandbox lifecycle, issues computation requests over Arrow Flight to isolated worker processes, and returns results as SQL column values, making agent logic a first-class SQL primitive. The dual Apache 2.0 / Elastic 2.0 licensing model clearly separates the open-source core from enterprise features (data masking, row access policies, storage encryption, hilbert clustering) gated behind a license key — a clean open-core boundary that is structurally enforced by the crate organization.

Self-Hosting

Databend uses a dual licensing model: the core database engine (query planner, pipeline executor, storage layer, vector search, full-text search) is licensed under Apache 2.0, which permits unrestricted commercial use, modification, and distribution with no copyleft obligations. Enterprise features — including data masking, row access policies, storage encryption, virtual columns, and advanced clustering — are licensed under Elastic License 2.0. The Elastic license permits self-hosting and internal use, but prohibits offering Databend as a managed service to third parties without a commercial agreement. The license boundary is structurally enforced: enterprise code lives exclusively in src/query/ee/ and src/meta/ee/, which are compiled only with the EE binary entry point.

Running Databend yourself requires deploying two components: databend-query (the stateless compute layer) and databend-meta (the distributed metadata service using Raft consensus). Both are single Go-free Rust binaries. Storage is entirely delegated to object storage (S3, GCS, Azure Blob), so there are no local disks to manage for data durability. Horizontal scaling of the query layer is straightforward — add more query nodes pointing at the same meta cluster and object storage bucket. However, operating the meta cluster (typically 3 nodes for HA) requires understanding Raft quorum and snapshot management. The project provides Docker images and a bendsave tool for backup, but teams must own monitoring, upgrades (nightly releases are cut frequently), and disaster recovery planning.

Databend Cloud (the managed SaaS) provides fully elastic compute warehouses that scale to zero, automated nightly upgrades, built-in HA, cloud-native backups, and enterprise support SLAs — capabilities that require significant operational engineering to replicate in a self-hosted deployment. The cloud tier also enables features like multi-cluster sharing and managed EE license activation without self-managing key distribution. Teams with strong Rust and distributed-systems expertise will find self-hosting tractable; teams wanting to focus purely on data workloads will benefit from the managed offering.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack

No spam. Unsubscribe anytime.

Join 750+ subscribers
No spam. Unsubscribe anytime.

Search