Skip to content
HeliosDB HeliosDB Nano

HeliosDB Nano v3.4.0 Release Notes

HeliosDB Nano v3.4.0 Release Notes

Release Date: January 2026 Previous Version: v3.3.0

Overview

HeliosDB Nano v3.4.0 is an Advanced SQL Features Release that extends PostgreSQL compatibility with JSON aggregation, array operations, and enhanced type verification. This release also includes transaction system improvements and comprehensive documentation updates.

Highlights

  • json_agg() Function: PostgreSQL-compatible JSON array aggregation for analytical queries
  • Array Operations: 1-based subscript indexing and || concatenation operator
  • Type Verification: Built-in validation for UUID, Boolean, and BYTEA types
  • Transaction Improvements: Enhanced lock management with RAII pattern
  • Documentation Sync: Fixed broken links and updated version references
  • 100% Backward Compatible: No API changes, drop-in replacement for v3.3.0

New Features

Phase 1.10: JSON Aggregation

The json_agg() aggregate function allows building JSON arrays from query results:

-- Aggregate user data into JSON array
SELECT json_agg(name) AS user_names FROM users;
-- Result: ["Alice", "Bob", "Charlie"]


-- With ORDER BY support
SELECT json_agg(product ORDER BY price DESC) AS products_by_price
FROM products;


-- Integration with GROUP BY
SELECT department, json_agg(name) AS employees
FROM staff
GROUP BY department;


-- Works with materialized views
CREATE MATERIALIZED VIEW customer_orders AS
SELECT customer_id, json_agg(order_id) AS order_ids
FROM orders
GROUP BY customer_id;

Implementation Details:

  • Full PostgreSQL compatibility for NULL handling
  • Type-safe JSONB output
  • ORDER BY support within aggregation
  • Seamless materialized view integration

Phase 2: Array Operations

Array Subscript Operator

Access array elements using 1-based indexing (PostgreSQL compatible):

-- 1-based indexing
SELECT ARRAY[10, 20, 30, 40, 50][1] AS first_element;
-- Result: 10


SELECT ARRAY[10, 20, 30, 40, 50][3] AS third_element;
-- Result: 30


-- Out-of-bounds returns NULL (safe indexing)
SELECT ARRAY[10, 20, 30][10] AS out_of_bounds;
-- Result: NULL


-- Use in WHERE clauses
SELECT * FROM products WHERE tags[1] = 'featured';

Array Concatenation

Combine arrays using the || operator:

-- Concatenate arrays
SELECT ARRAY[1, 2, 3] || ARRAY[4, 5, 6] AS combined;
-- Result: [1, 2, 3, 4, 5, 6]


-- Type coercion
SELECT ARRAY[1, 2] || ARRAY[3.5, 4.5] AS mixed;
-- Result: [1.0, 2.0, 3.5, 4.5]


-- Dynamic array building
SELECT user_id, favorite_items || recent_items AS all_items
FROM user_preferences;

Phase 3: Type Verification

Enhanced type system validation for:

  • UUID: Format validation for 128-bit identifiers
  • Boolean: Strict true/false validation
  • BYTEA: Binary data type support

Improvements

Transaction System Enhancements

  • RAII Lock Guards: Automatic lock release on transaction commit/rollback
  • Lock Manager Integration: Session-aware locking with deadlock detection
  • DashMap Optimization: Lock-free concurrent access to write sets
// Example: RAII pattern ensures locks are released
pub struct LockGuard {
    lock_manager: Arc<LockManager>,
    resource: String,
    txn_id: u64,
}


impl Drop for LockGuard {
    fn drop(&mut self) {
        // Automatic lock release
        self.lock_manager.release_lock(&self.resource, self.txn_id);
    }
}

Documentation Updates

  • Fixed 8 broken documentation links in README.md
  • Updated version references from v3.0 to v3.4.0
  • Synchronized architecture documentation with implementation
  • Added feature status alignment document

Known Issues

Transaction Isolation in Concurrent Scenarios

Issue: The concurrent banking test (test_10_concurrent_users_5_transactions_each) is currently ignored due to a known limitation with transaction isolation in concurrent read-modify-write scenarios.

Root Cause: Lost update anomaly in concurrent UPDATE statements. When multiple transactions perform read-modify-write operations on the same row:

  1. Transaction A reads balance = 1000
  2. Transaction B reads balance = 1000 (before A commits)
  3. Transaction A writes balance = 900
  4. Transaction B writes balance = 900 (overwrites A’s result)

Current Status: The test is marked with #[ignore] for investigation. For applications requiring strict serializable isolation in concurrent updates:

Workarounds:

  1. Use application-level optimistic locking with version checks
  2. Use SELECT ... FOR UPDATE semantics (planned for future release)
  3. Serialize updates at the application level

Tracking: See tests/integration/multi_user_scenarios.rs for details.

Test Suite Status

CategoryCountStatus
Unit Tests883All Passing
Integration Tests34Passing
Ignored Tests1Known Issue (documented)

Upgrade Guide

From v3.3.0

No action required. v3.4.0 is a drop-in replacement:

Terminal window
# Update Cargo.toml
[dependencies]
heliosdb-nano = "3.4"


# Or install CLI
cargo install heliosdb-nano

Breaking Changes

None. This release maintains full backward compatibility.

Build Information

  • Binary Size: ~20MB (release build)
  • Rust Version: 1.75+
  • Target: x86_64-unknown-linux-gnu
  • Dependencies: RocksDB 8.10, Arrow 52.2

What’s Next (v3.5.0)

  • CDC Persistence Layer
  • Automatic Change Capture hooks
  • RETURNING Tuple Capture optimization
  • Background Replication Tasks
  • SELECT FOR UPDATE support

Contributors

  • HeliosDB Team