---
title: 'Databend Monthly Report: January 2026 — Table Branching & Tags, Spatial Indexes'
date: 2026-02-04
slug: category-product/monthly-jan2026
cover_url: '202601/blog-title.png'
description: 'January delivered 11 nightly releases focused on data governance and query performance, including experimental Table Branching/Tags, Spatial Indexes for Geometry/Geography, and Iceberg write support—plus major engine and meta-service upgrades.'
tags: [databend, monthly]
category: Product
authors:
  - DatabendLabs
---

import BlogSignupAD from '@site/src/components/blog-signup-ad';

# Databend Monthly Report: January 2026 — Table Branching & Tags, Spatial Indexes

Hello Databend community, 🚀

January delivered **11 nightly releases** with a strong focus on **Data Governance** and **Query Performance**. We shipped initial support for **Table Branching / Tag**, providing powerful tools for data version control; **Spatial Index** support now fully covers Geometry/Geography workloads for faster spatial analysis; and **Iceberg Write** capabilities are officially live. On the engine side, we continued to reduce latency with Self-join Elimination, Lazy Materialization across Joins, and Fuse Parquet Prewhere optimizations, while the Meta service saw significant upgrades and refactors.

{/* truncate */}

## By the Numbers

From v1.2.863-nightly to v1.2.873-nightly, we merged **33 new features**, **31 bug fixes**, **37 refactors**, **3 CI/build improvements**, and **15 quality-of-life updates**.

## Monthly Highlights

### 🔥 Major New Features

- **Table Branching & Tags (Experimental)** — Branch/Tag DDL plus the `tag_references` table function make data governance and tracking simple and efficient.
- **Spatial Index** — `CREATE/DROP SPATIAL INDEX` now supports Geometry/Geography workloads, boosting spatial query performance.
- **Iceberg Write Support** — Upgraded to iceberg-rust v0.8.0, enabling the write path and enhancing open data lake compatibility.
- **Stage & Connection Management** — Added `ALTER STAGE`, database-level default connection config, and richer `system.stages` / `SHOW STAGES` information.
- **Parquet Inspection Utilities** — New table functions for inspecting Parquet pages, aiding in low-level storage troubleshooting.

### ⚙️ Query Performance & Engine

- **Self-join Elimination + Constant Subquery Elimination** — Intelligently removes redundant calculations and simplifies complex query plans.
- **Lazy Materialization across Joins** — Optimizes NULL handling in outer joins while reducing I/O overhead.
- **Fuse Parquet Prewhere + DataBlockVec** — faster multi-block reads and more efficient block slicing.
- **High-Performance Bitmap Ops** — `bitmap_count` / `bitmap_intersect` now execute without deserialization for significant speedups.
- **Experimental Hash Join Path** — Added Nested Loop Join support to complete the join strategy coverage.

### 🧩 Semistructured & Time

- **Variant -> TimestampTz** — Support for casting from Variant with second-level offset precision for better timezone fidelity.
- **JSON Compatibility** — Standardized nested-type quoting and Variant serialization to ensure consistent behavior.
- **Format Polish** — Binary I/O enhancements and CSV/TSV decimal outputs now automatically trim trailing zeros.
- **Table Functions** — Scalar subquery arguments are now supported for greater flexibility.

### 🛠️ Meta & Operations

- **Meta Observability** — Added request latency histograms and configurable connection TTL for richer monitoring.
- **KV APIs** — Introduced KvList / KvGetMany gRPC APIs plus list limits for faster key scans.
- **Meta Runtime Upgrades** — Upgraded Openraft and refactored multiple runtime components for improved cluster stability.

### 🐛 Reliability & Quality

- Fixed Inverted-Index matching for JSON arrays; result cache keys now correctly include secure filter predicates.
- Hash Shuffle uses full join keys to avoid skew; added Parquet page overflow prevention.
- Fixed Stage drop/replace file cleanup on OSS; resolved stream diff aliasing and recursive CTE edge cases.

## Spotlight: Table Branching & Tag (The Perfect Data Sandbox for Agents)

Why do **Data Agents** need Table Branching?

One of the biggest challenges in building AI Agents that can write SQL, clean data, or perform complex analysis is **safety**. You definitely don't want an Agent's trial-and-error process to dirty or delete production data.

**Table Branching provides a natural data sandbox for Agents.**

- **Safe Experimentation (Sandbox for Agents)**: Agents can create a temporary **Branch** for a task. On this branch, the Agent has full read/write permissions to execute `DELETE`, `UPDATE`, or complex ETL operations. No matter how drastically the Agent modifies the branch, the Main Table remains untouched.
- **Verification & Merge**: Once the Agent's operations on the branch are verified (e.g., the generated SQL produces the expected results, or data quality checks pass), you can then consider applying the logic back to the main branch.
- **Time Travel**: Combined with Tags, you can mark every successful Agent task or create snapshots before execution, allowing for instant rollback at any time.

This makes Databend not just a high-performance data warehouse, but a true **Agent-Ready Database**.

### 💡 Example in Action

```sql
-- Enable the feature flag if your environment still requires it
SET enable_experimental_table_ref=1;

-- 1. Prepare base data
CREATE OR REPLACE TABLE sales.orders(id INT, amount INT);
INSERT INTO sales.orders VALUES (1, 100), (2, 200);

-- 2. Create Branch and Tag
-- Create a 'dev' branch for development/testing
ALTER TABLE sales.orders CREATE BRANCH dev;
-- Create a 'v1_0' tag as a data milestone
ALTER TABLE sales.orders CREATE TAG v1_0;

-- 3. Modify data on the Branch (Does not affect Main Table or Tag)
INSERT INTO sales.orders/dev VALUES (3, 300);

-- 4. Verify Data Isolation
SELECT * FROM sales.orders ORDER BY id;      -- Main: 1, 2
SELECT * FROM sales.orders/v1_0 ORDER BY id; -- Tag v1_0: 1, 2 (Read-only)
SELECT * FROM sales.orders/dev ORDER BY id;  -- Branch dev: 1, 2, 3 (Contains new data)

-- 5. Advanced Usage: Derive from existing Refs
-- Create a new 'qa' branch from 'dev' with 7-day retention
ALTER TABLE sales.orders CREATE BRANCH qa AT (BRANCH => dev) RETAIN 7 DAYS;
-- Create a backup tag from 'v1_0'
ALTER TABLE sales.orders CREATE TAG v1_0_copy AT (TAG => v1_0);
```

---

<BlogSignupAD title="Ready for Table Branching and Spatial Indexes?" />