Thinking in tables: Why Deephaven's table-oriented approach changes everything

You've just spent three hours debugging why your real-time trading system is dropping updates, managing complex state synchronization between different software components, and wondering why your "simple" analytics pipeline feels like you're wrestling with an octopus. Sound familiar?

There's a better way. What if I told you that the most successful Deephaven applications don't build complex software architectures at all?

Deephaven is fundamentally different from traditional databases and analytics tools. While other platforms bolt real-time capabilities onto existing architectures, Deephaven was built around live, updating tables. This blog shows why this architectural choice matters through a clear example of table-oriented thinking.

Why Deephaven's approach is different

Other real-time platforms make you choose between performance and simplicity. Deephaven's table-oriented architecture provides:

Simplicity: Your code becomes declarative — describe what you want, and Deephaven's engine handles the orchestration of real-time updates automatically.
Performance: Tables update incrementally, not through full recalculations, processing millions of updates per second while maintaining microsecond latencies.
Faster development: Deploy real-time analytics quickly. Add new data sources, calculations, or consumers without architectural changes.

The most successful Deephaven applications work with the platform's strengths. When you embrace table-oriented thinking instead of forcing traditional patterns, everything becomes simpler, faster, and more maintainable.

The paradigm shift: From objects to tables

Traditional software development teaches us to model business concepts as separate software components (called "objects" or "classes" in programming). A trading system might have separate PriceFeed, Trade, and Portfolio components, each managing their own data and logic - but in Deephaven's table-oriented world, these business concepts become tables with relationships.

Here's the key conceptual mapping: In object-oriented programming, you work with individual objects. In table-oriented programming, you work with rows.

An object (like a specific Trade instance) → A row in a table.
A collection of objects (like a list of trades) → A table of rows.
Object properties (like trade.symbol or trade.quantity) → Table columns.
Methods that transform objects → Table operations.

This isn't just terminology — it's a different way of thinking about data:

# OOP: Individual objects - conceptual comparison
trade1 = Trade(symbol="AAPL", quantity=100, price=150.25)
trade2 = Trade(symbol="GOOGL", quantity=50, price=2800.50)
trades = [trade1, trade2]  # Collection of objects

# Table-oriented: Rows in a table
# Each row represents what would have been an object
trades = create_table(
    {"Symbol": ["AAPL", "GOOGL"], "Quantity": [100, 50], "Price": [150.25, 2800.50]}
)

The power of this shift becomes clear when data changes. In OOP, you manage individual object updates. In table-oriented programming, entire rows update automatically, and those updates cascade through your entire dependency graph.

In Deephaven, key concepts are represented as tables instead of classes. This isn't just a different syntax - it's a fundamentally different way of thinking about data and computation.

Visual comparison: OOP vs. table-oriented flow

A real customer example

This isn't theoretical. Here's actual code from our customer support team showing a developer how to build a real-time analytics system using table-oriented design. The example demonstrates a complete trading workflow — from live price feeds and trade execution to portfolio tracking and analysis. Notice how every business concept (prices, trades, positions) becomes a table, and how their relationships are expressed through simple table operations rather than complex event handlers:

import random
from deephaven import new_table, updateby as uby
from deephaven.column import string_col, double_col, int_col
from deephaven.time import dh_now

# Set up a price feed with sample data
base_time = dh_now()
prices = new_table(
    [
        string_col("Sym", ["A", "B"] * 5),
        double_col("Price", [100.0 + random.uniform(-2, 2) for _ in range(10)]),
    ]
).update("Timestamp = base_time + i * SECOND")

# Set up a trade feed
trades = (
    new_table(
        [
            string_col("Sym", ["A", "B"] * 5),
            int_col("Size", [random.randint(-1000, 1000) for _ in range(10)]),
        ]
    )
    .update(
        [
            "Timestamp = base_time + i * SECOND",
            "Direction = Size > 0 ? `LONG` : `SHORT`",
        ]
    )
    .aj(prices, ["Sym", "Timestamp"], ["Price"])
)

# Compute portfolio views -- these could also be feeds
portfolio_hist = trades.update_by([uby.cum_sum("Size")], "Sym")
portfolio = portfolio_hist.drop_columns("Direction").last_by("Sym")

# Do some trade analysis
analysis = trades.aj(
    prices.update_view(
        ["FutureTimestamp=Timestamp", "Timestamp=Timestamp-'PT00:01:00'"]
    ),
    ["Sym", "Timestamp"],
    ["FuturePrice=Price"],
).update_view("PriceChange = FuturePrice-Price")

Key concepts

Let's examine what makes this approach so powerful.

Tables as entities

Notice how each key concept is represented as a table:

Price feed → prices table
Trade feed → trades table
Portfolio history → portfolio_hist table
Current portfolio → portfolio table
Trade analysis → analysis table

Each table isn't just storing data — it's a living, updating entity that represents a business concept.

Table relationships

Instead of method calls between objects, we have table operations that express relationships:

# AsOf join to get the current price for each trade - conceptual example
trades = trades.aj(prices, ["Sym", "Timestamp"], ["Price"])

# Cumulative sum to build portfolio history
portfolio_hist = trades.update_by([uby.cum_sum("Size")], "Sym")

# Get current positions
portfolio = portfolio_hist.last_by("Sym")

These operations create a dependency graph where changes in one table automatically propagate to dependent tables.

Real-time by default

In object-oriented systems, you typically need to implement observers, event handlers, or polling to keep derived data up-to-date. With Deephaven's table-oriented approach, updates flow automatically:

New prices in the prices table automatically update trades.
New trades automatically update portfolio history.
Portfolio history changes automatically update current positions.

Mental model shift

Before: OOP

# Traditional OOP approach (pseudocode) - not executable
class PriceFeed:
    def __init__(self):
        self.subscribers = []

    def update_price(self, symbol, price):
        # Update internal state
        # Notify all subscribers

class Portfolio:
    def __init__(self):
        self.positions = {}

    def on_trade(self, trade):
        # Update positions
        # Recalculate metrics

After: Tables

# Deephaven table-oriented approach - conceptual example
prices = create_price_feed()  # Returns a table
trades = create_trade_feed().aj(prices, ...)  # Table with relationships
portfolio = trades.update_by([uby.cum_sum("Size")], "Sym")  # Derived table

The table-oriented approach eliminates the complexity of managing state, notifications, and synchronization — it's all handled automatically by the table engine.

What this means for your development workflow

Before (OOP approach):

50+ lines of state management code.
Manual synchronization between components.
Hours debugging race conditions and update ordering.
Brittle code that breaks when requirements change.
Complex observer patterns and event handling.

After (Table-oriented approach):

10 lines of declarative table operations.
Automatic updates across your entire system.
Zero race conditions by design.
Requirements changes = adding new table operations.
Natural composability—outputs become inputs seamlessly.

Key benefits

1. Composability

Tables compose naturally. The output of one table operation becomes the input to another, creating data pipelines. You build complex systems by connecting simple, reusable operations:

# Each step builds on the previous - conceptual example
raw_data = time_table("PT1S")
enriched = raw_data.aj(reference_data, ["Key"])
aggregated = enriched.agg_by([agg.avg("Value")], "Category")
alerts = aggregated.where("Value > threshold")

2. Automatic dependency management

Deephaven tracks relationships between tables and propagates updates efficiently. When data changes, only affected computations run — no manual synchronization, no race conditions, no stale data.

3. Declarative simplicity

You describe what you want, not how to compute it. Deephaven handles real-time updates, state management, and incremental calculations automatically:

# Declarative: "I want the average price by symbol" - conceptual example
avg_prices = trades.agg_by([agg.avg("Price")], "Sym")

# vs. imperative: manually managing state and calculations

Making the transition

1. Identify your core entities

Start by listing the key business concepts in your domain:

What are the main data sources?
What derived metrics do you need?
What are the relationships between entities?

2. Map entities to tables

For each entity, create a table that represents it:

Raw feeds become source tables.
Calculations become derived tables.
Aggregations become summary tables.

3. Express relationships

Use Deephaven's table operations to express how entities relate:

update and view for creating and transforming columns.
where for filtering data.
agg_by for grouping and aggregation.
update_by for running calculations and windowed operations.
aj and other joins for combining tables based on keys and time.
sort, head, tail, and last_by for ordering and selecting data.

4. Think data flow

Design your system as a flow of data through transformations rather than a collection of interacting objects.

Real-world architecture

The table-oriented approach works well for complex, event-driven architectures. Consider an automated trading system:

# 1. Market data feed (real-time table) - conceptual architecture example
market_data = get_market_feed()

# 2. Trading signals (derived table)
signals = market_data.where("volume > threshold").update(
    [
        "signal_strength = calculate_signal(price, volume)",
        "action = signal_strength > 0.7 ? 'BUY' : signal_strength < -0.7 ? 'SELL' : 'HOLD'",
    ]
)

# 3. Order generation (filtered table)
orders = signals.where("action != 'HOLD'").update(
    [
        "order_id = timestamp_nanos",
        "symbol = sym",
        "quantity = calculate_position_size(signal_strength)",
        "order_type = 'MARKET'",
    ]
)

# 4. Trade results (input table for external system integration)
trade_results = get_trade_feed()

Tables naturally support event-driven patterns. When new market data arrives, updates automatically flow through the dependency chain:

New market data → triggers signal calculation.
New signals → triggers order generation.
New orders → triggers external system notification.
Trade results → triggers portfolio updates.

Your next 15 minutes

Don't just read about table-oriented thinking —- experience it:

Try the example: Copy the customer support code into a Deephaven session and watch tables update in real-time.
Identify one pain point in your current analytics code where you're managing state manually.
Reimagine it as tables: What would those entities look like as living, updating tables?

When you make this mental shift, what seemed complex becomes clearer. The paradigm works with you instead of against you.

The bottom line

Table-oriented thinking changes how you build real-time systems. Instead of managing event processing frameworks, message queues, and state synchronization, you describe what you want:

Faster development: Build systems in days instead of months, with automatic consistency.
Flexible architecture: Add requirements without rewrites — the dependency graph adapts naturally.
Lower complexity: Developers at all levels can build sophisticated systems because complexity is handled at the platform level.

When you're designing a real-time system, the choice is straightforward: spend time building your analytics logic, or spend time building infrastructure.

The next time you're designing a real-time system, ask yourself: "Do I want to build analytics, or do I want to build infrastructure?"

Deephaven lets you focus on what matters: your business logic, not your plumbing.

Start your table-oriented journey with our quickstart guide to get hands-on experience, or explore our how-to guides for specific patterns and techniques.

From objects to tables: A paradigm shift for real-time analytics