Real-time context

Real-time serving turns FeatureQL into a feature platform for production APIs and online ML inference. Instead of building custom microservices to fetch and combine data from Redis, PostgreSQL, and REST APIs, you declare what you need and FeatureMesh handles the rest.

Data source connectors

FeatureQL connects to operational data stores through three connector types:

Each connector follows the same pattern: create a persistent source connection, then reference it in feature definitions. The next three pages walk through each one.

Composing multiple sources

Because features are just named expressions, you can freely mix connectors in a single query. A feature might look up a customer in PostgreSQL, fetch their latest order from Redis, and call an external scoring API over HTTP — all in one request. FeatureMesh resolves the dependency graph and queries each source using its native access pattern. The multi-source queries page shows this in action.

From prototyping to production

Free-form queries work for development and testing, but production deployments should use prepared statements. A prepared statement pre-compiles a feature and its entire dependency graph — including all data source calls — into a single optimized query. Clients call it via REST or gRPC with just the input values, eliminating parsing and resolution overhead. See prepared statements for details.

Real-time constraints

Real-time serving focuses on individual feature retrieval, not analytical queries. A few capabilities from batch analytics are not available:

• No presentation layer: WHERE, GROUP BY, ORDER BY, and LIMIT clauses are not supported in real-time contexts.
• No aggregations: RELATED() and EXTEND() aggregations are not available. Use precomputed aggregates or prematerialized collections of IDs as sources for your features.