Multi-source queries

The previous pages each covered a single connector — Redis, JDBC, HTTP. In practice, the data you need for a feature often lives in more than one system. FeatureQL lets you mix connectors freely in a single query: look up a customer in PostgreSQL, fetch their latest order from Redis, and combine the results — all without writing any orchestration code.

Combining Redis and PostgreSQL

This query retrieves customer data from PostgreSQL and enriches it with order details from Redis:

FeatureQL
WITH
    -- The details on orders are in redis
    ORDERS := ENTITY(),
    ORDER_ID := INPUT(BIGINT#ORDERS),
    REDIS_KEY := 'order:' || ORDER_ID::VARCHAR,
    ORDER_DETAILS_STR := EXTERNAL_REDIS(KEY REDIS_KEY FROM FM.DEMO1.REDIS_SRC),
    ORDER_DETAILS := JSON_PARSE_AS(ORDER_DETAILS_STR, TYPE 'ROW(order_id BIGINT, price FLOAT)'), -- VARCHAR TO ROW
    -- The details on customers are in postgres
    CUSTOMERS := ENTITY(),
    CUSTOMER_ID := INPUT(BIGINT#CUSTOMERS),
    CUSTOMER_DETAILS := EXTERNAL_COLUMNS(
      customer_id BIGINT BOUND TO CUSTOMER_ID,
      last_order_id BIGINT#ORDERS
      FROM VIEW(FM.DEMO1.POSTGRES_CONN[customers_view])
    ),
    LAST_ORDER_ID := CUSTOMER_DETAILS[last_order_id],
    -- Join between the two
    LAST_ORDER_JOIN := EXTEND(
        ROW(LAST_ORDER_ID as last_order_id)
        WITH ORDER_DETAILS AS order_details
        VIA last_order_id BOUND TO ORDER_ID  -- Optional but clearer with
    ),
    LAST_ORDER_PRICE := LAST_ORDER_JOIN[order_details][price]
SELECT
    CUSTOMER_ID := BIND_VALUES(ARRAY[1,2,4]),
    LAST_ORDER_PRICE
ORDER BY CUSTOMER_ID;
Result
CUSTOMER_ID BIGINTLAST_ORDER_PRICE VARCHAR
119.99
212.74
460.00

The query defines two entities backed by different data stores. CUSTOMERS lives in PostgreSQL (via EXTERNAL_COLUMNS()), ORDERS lives in Redis (via EXTERNAL_REDIS()). The EXTEND() call bridges the two: it takes the last_order_id from the PostgreSQL result and uses it to look up order data in Redis, linking them through the BIGINT#ORDERS entity annotation.

FeatureMesh resolves the dependency graph automatically — it knows to query PostgreSQL first (to get last_order_id), then Redis (to fetch the order details). Each source is queried using its native access pattern: parameterized SQL for PostgreSQL, key-based lookup for Redis.

How it works

There is no special syntax for multi-source queries. You simply define features that reference different connectors, and FeatureMesh figures out the execution order from the dependency graph. The same mechanisms that resolve feature dependencies within a single source work across sources.

This means any query you build with individual connectors can be extended to span multiple sources — just add more features that reference other connectors and link them through entity annotations or EXTEND().

Taking it to production

Once you have a multi-source query working, you can compile it into a prepared statement for production serving. The prepared statement captures the entire dependency graph — including all cross-source joins — into a single pre-compiled unit. Clients call it with just the input values, and FeatureMesh handles the rest.

Last update at: 2026/02/17 19:13:00
Last updated: 2026-02-17 19:13:38