Unistore & Hybrid Tables Update

Snowflake has traditionally been an OLAP (Online Analytical Processing) engine. It’s meant for scanning billions of rows to find aggregates. It was terrible at searching for a single row by ID or updating individual statuses 50 times a second.

Unistore and Hybrid Tables promise to bridge this gap, bringing OLTP (Online Transactional Processing) workloads to Snowflake. Now that we are well into 2025, how is it holding up?

What are Hybrid Tables?#

Hybrid tables are a new table type (CREATE HYBRID TABLE) that uses a row-oriented storage engine (similar to Postgres) alongside the traditional columnar micro-partitions.

• Primary Keys: Enforced! (Unlike standard Snowflake tables).
• Indexes: Supports secondary indexes for fast lookups.
• Locking: Row-level locking for high concurrency updates.

Use Cases in 2025#

We are seeing three main patterns emerging:

1. App Backends: Lightweight internal apps (e.g., Streamlit apps) that need to store user state, preferences, or audit logs. Instead of spinning up a separate RDS instance, just use a Hybrid Table.
2. State Stores: Storing the “current state” of an order or transaction for fast lookup APIs, while simultaneously joining it with historical OLAP data for analytics.
3. Rapid Ingestion: Serving as a high-throughput landing zone before data is moved to OLAP tables.

Performance vs. Cost#

Hybrid tables are more expensive than standard tables. You pay for:

• Storage: Higher cost per GB (since it’s SSD-optimized row storage).
• Throughput: Read/Write request units (similar to DynamoDB capacity modes).

Do not migrate your 50TB Data Warehouse facts to Hybrid Tables. You will go bankrupt, and it will be slower. Use them for “hot”, heavily transactional data subsets (GBs, not TBs).

Semantic Consistency#

The killer feature is that you can JOIN a Hybrid Table with a Standard Table seamlessly.

SELECT
    o.order_id,          -- From Hybrid (Real-time status)
    o.status,
    c.lifetime_value     -- From Standard (Deep history)
FROM app_db.orders_hybrid o
JOIN analytics_db.customers_standard c
  ON o.customer_id = c.customer_id;

This eliminates the “ETL lag” between your operational systems and your analytical reporting for key use cases.

Conclusion#

Unistore isn’t trying to kill Oracle or Postgres for your core banking ledger just yet. But for the “Data Layer” of modern data applications, it simplifies the stack immensely by removing the need for a separate operational database.