Functional compatibility was tested on 2026-10-06 with connector 0.4.1-SNAPSHOT at commit de16df3, Trino 483, and Temurin Java 25.0.4.1. The same targeted Trino probe exercised 11 checks: catalog connection, TAG table creation, INSERT, row scans, TAG predicate pushdown, COUNT, ADD COLUMN, UPDATE/readback, DELETE/readback, NUMERIC table creation, and SUM. These results cover that probe; they do not establish full-suite coverage or performance characteristics.

Both local databases ran on the same single-node redislabs/redis:latest container; the version above records the actual tested build. Connector settings were redisearch.default-schema-name=tpch, redisearch.scan-connections=1, and redisearch.cluster=false. Tests used redis:// connections, a temporary ACL user scoped to the Cloud databases, and no authentication on the local test endpoints. Temporary users, roles, databases, indexes, and test hashes were removed after testing.

First, you’ll need a working Trino installation.

See the Trino installation and deployment guide for details. Trino recommends a container-based deployment using your orchestration platform of choice. If you run Kubernetes, see the Trino Helm chart.

Next, you’ll need to install the Redis SQL Trino plugin and configure it. See our documentation for plugin installation and plugin configuration.

The fieldengineering/redis-sql-trino image is trinodb/trino:483 with the connector installed, for linux/amd64 and linux/arm64. The early-access tag is built from every push to master; latest and version tags are published with each release.

On Linux, add --add-host=host.docker.internal:host-gateway to reach a Redis running on the host.

When any of these environment variables is set, the container writes the redisearch catalog from them; unset ones get the default shown.

The container runs a single-node Trino cluster by default. For a multi-node cluster, set TRINO_NODE_TYPE to coordinator or worker on each container, and TRINO_DISCOVERY_URI to the coordinator’s URL (default http://localhost:8080).

For a self-managed deployment, or for testing locally, install Redis 8 (for example, docker run -p 6379:6379 redis:8.4) or spin up a free Redis Cloud instance. If you need a fully-managed, cloud-based deployment of Redis on AWS, GCP, or Azure, see all of the Redis Cloud offerings. For deployment in your own private cloud or data center, consider Redis Enterprise.

Trino can query the hashes and JSON documents your applications already write, as long as a Query Engine index covers them. It doesn’t scan keys: SHOW TABLES lists the indexes from FT._LIST, and keys that no index covers are invisible to Trino.

To query existing data, create an index over its key prefix with FT.CREATE. The Quick start does this for the beer hashes:

The index is now the table beers, with no change to Trino:

• Each indexed field is a column: NUMERIC fields are DOUBLE, and all other field types are VARCHAR. For JSON paths, the column is named by the AS alias. Filters on these columns can run in Redis (see Pushdown below).

• Fields that aren’t indexed but appear in the first 10 documents of FT.SEARCH beers * are VARCHAR columns too. You can select them, but Trino evaluates filters on them itself.

• For JSON indexes, a $ column holds the whole document as JSON text.

• A hidden __key column holds each document’s Redis key. SELECT * leaves it out, so name it: SELECT __key, * FROM beers.

FT.CREATE indexes the existing keys in the background, and queries on the index fail with REDISEARCH_INDEX_NOT_READY until it finishes. From then on, Redis indexes each key as it’s written, so rows your applications add appear in the next query. Fields added to an index outside Trino can take up to redisearch.table-cache-refresh seconds (default 60) to appear as columns.

Use FT.CREATE rather than CREATE TABLE for data that already exists. CREATE TABLE creates its index with SKIPINITIALSCAN, so it only indexes keys written after it. Don’t run DROP TABLE on an index over application data unless you mean to delete that data: it drops the index and every document it covers.

Redis returns the matching documents in batches of redisearch.cursor-count rows (default 1000). The connector reads each batch while Trino processes the one before it. Each table scan is a single split, so one Trino worker reads the whole index. Redis rounds NUMERIC fields loaded by name to 12 significant digits, so a scan that reads DOUBLE or DECIMAL columns loads hashes with LOAD and JSON documents with DIALECT 3, which return the values as stored. LOAD * returns every field of each hash, so BIGINT columns are loaded by name: Redis returns an integer in full, and only a value of 2^53 or more may be rounded, which the connector reads again with HGET. The results of GROUPBY and REDUCE are rounded that way. With GROUP BY and count(), min, max, sum or avg, Redis computes the groups too (GROUPBY and REDUCE) when it evaluates the whole WHERE clause, and only the aggregated rows come back. A query with nothing to push down reads every document in the index.

• Each row becomes a new hash. Its key is the index’s first key prefix followed by a generated ULID, with a : added if the prefix doesn’t end in one. Tables made with CREATE TABLE use the prefix <table>:.

• The key doesn’t come from any column, and INSERT never overwrites. Inserting a row whose id is '190' adds a second hash next to beer:190 rather than replacing it. Use UPDATE or MERGE to change existing documents.

• Each non-null value becomes a hash field named after its column. NULLs, and columns the INSERT leaves out, aren’t written.

• Values are stored as strings: VARCHAR as is, BIGINT and other integers as digits, and DOUBLE as Java formats it, so 6 is stored as 6 in a BIGINT column and as 6.0 in a DOUBLE column.

• Rows are sent as pipelined HSET commands, one batch per page of rows, outside any transaction. If an INSERT fails partway, the rows it already wrote stay in Redis.

• The connector only writes hashes. INSERT into a JSON index writes a hash under <table>: that the index never sees (#44).

Applications read these rows like any other hash, for example with HGETALL.

UPDATE, DELETE and MERGE first find the matching rows and their keys with FT.AGGREGATE, then change those keys.

These aren’t supported:

• Schemas: CREATE SCHEMA, DROP SCHEMA, ALTER SCHEMA

• Views: CREATE VIEW, CREATE MATERIALIZED VIEW

• CREATE OR REPLACE TABLE, TRUNCATE and COMMENT ON

• Other table changes: ALTER TABLE ... RENAME TO, DROP COLUMN, RENAME COLUMN and SET DATA TYPE

• Writes with fault-tolerant execution (retry-policy other than NONE)

Redis evaluates these parts of a query. Trino evaluates everything else on the rows Redis returns.

• WHERE on indexed fields, combined with AND: = and IN; and <, <=, >, >= and BETWEEN on NUMERIC fields. Columns created through Trino as BOOLEAN, DATE, UUID or CHAR are queried as TAG fields, and as REAL, DECIMAL (of up to 15 digits), TIMESTAMP(3) or TIMESTAMP(3) WITH TIME ZONE as NUMERIC fields, comparing values as the connector writes them. On TAG and TEXT fields, the query also matches rows that aren’t equal. A TEXT query finds the documents containing the value’s words. A TAG query matches any of the tags Redis splits a value into on the field’s SEPARATOR, ignoring surrounding whitespace and, unless the field is CASESENSITIVE, case. A FILTER step then keeps the rows equal to the value; scans of JSON documents keep them in the connector. For values with control characters, Trino filters them instead. Trino evaluates LIKE, IS NULL, IS NOT NULL, and comparisons other than = and IN on VARCHAR columns.

• count(*), min, max, sum and avg on numeric columns, with or without GROUP BY, when Redis evaluates the whole WHERE clause

• sum and avg of arithmetic on DOUBLE columns of hash indexes, such as sum(quantity * extendedprice), which an APPLY step computes

• LIMIT, when Redis evaluates the whole WHERE clause

• ORDER BY …​ LIMIT on hash indexes, when Redis evaluates the whole WHERE clause and every sort key is an indexed NUMERIC column of type DOUBLE, REAL, INTEGER, SMALLINT or TINYINT, ordered NULLS LAST (the default). Redis sorts documents without a value last and returns only the first rows, which Trino then sorts.

• Join keys: in a join, the keys that the other side collects (its dynamic filter) are added to the query of a scan that Redis evaluates them in, under the same rules as WHERE. More than 256 keys become the range they span. A scan waits for them for up to redisearch.dynamic-filtering.wait-timeout (default 20s).

Each table’s row count is its index’s document count (num_docs in FT.INFO, cached with the table), so Trino’s cost-based optimizer can order joins and broadcast the smaller side of a join. Filters that Redis evaluates aren’t estimated, so a filtered table’s row count is its whole index’s.

Queries known to return wrong results or fail are tracked as open issues labeled bug.

See the SQL support documentation for column types in CREATE TABLE and more detail on each statement.

These are the query benchmark’s timings for commit 68202c8 (October 5, 2026), from the Benchmark job of its pull request (#100); master merged that code as a43401c. That job runs on a GitHub Actions ubuntu-latest runner, with Trino in the test JVM and Redis in a one-shard database on a single-node Redis Enterprise Software 8.2 container. The data is TPC-H tiny: 60,175 lineitem rows, 15,000 orders and 1,500 customer. Queries run with Trino’s default join_distribution_type=AUTOMATIC. Each query ran 5 times to warm up and was then timed 20 times, from submitting it to receiving its last row, in each of two runs. The table pools the 40 samples.

In those measurements, queries that Redis filtered, aggregated, sorted or limited finished in about 100 ms or less, because only the matching rows came back to Trino. So does a selective join: the keys of the 60 matching customers are added to the orders query, so Redis returns only their orders. At that measured commit, summing quantity * extendedprice over lineitem returned every row and took about 0.6 s. Since #111, supported arithmetic sum and avg expressions run in Redis, as measured below; the historical table above does not describe their current execution plan.

Timings vary by up to 2x from one runner to another, so compare builds of the connector within one Benchmark job rather than across runs. Don’t use them to size a deployment either: Trino and Redis share the runner’s CPUs, and a production cluster runs them on separate machines. To time the queries yourself, see Building from source.

A local benchmark on October 6, 2026 compared fb799bd, an early Trino 483 snapshot before v0.4.0, with 0869b8e. Both builds used Trino 483 and Temurin Java 25.0.4.1 on the same ARM64 Mac with 10 logical CPUs, with Trino in the test JVM and Redis in a redis:8.4 container. They used the same data loader, index schemas and TPC-H tiny data described above, with join_distribution_type=AUTOMATIC. The older build’s scan cap was set to 100,000, above every table’s row count. Connector production code was unchanged; the test harness was adapted to use the same Redis container and queries on both builds.

The builds ran sequentially in the order earlier/current/earlier/current. Each query had 5 warmup executions and 20 timed executions per run; the medians below pool 40 samples per build. Before timing, representative SELECT results were checked against TPC-H for row counts and sorted values, with numbers rounded to six significant digits. The limit and metadata queries were checked for stable result row counts only.

The arithmetic aggregate, selective join and top-N query benefit from doing more work in Redis and returning fewer rows to Trino. The sin(quantity) query still reads all 60,175 rows into Trino, so its improvement measures the scan path. Simple filters, limits, point lookups, grouping and metadata queries showed no clear improvement: their median changes ranged from about 13% slower to 9% faster, with overlapping interquartile ranges.

The concurrent point lookup is a tradeoff: the background arithmetic aggregates stream rows to Trino in the earlier build, but execute inside Redis in the current build. The slowdown is consistent with increased contention in Redis. These measurements cover reads and metadata on a single Redis container; writes were excluded because the older snapshot has known write correctness issues, and sharded databases were not tested. They do not establish an overall workload speedup or production capacity, and their absolute timings should not be compared with the separate CI run above. This comparison predates the subsequent read-ahead and contention changes described below.

Scans prefetch one cursor batch while Trino processes the previous batch. Reading two batches ahead improved scan throughput but delayed lookups sharing a connection; #117 restored one-batch read-ahead. The benchmark now distinguishes a real scan (max(quantity * extendedprice), computed by Trino) from a pushed-down aggregation (sum(quantity * extendedprice), computed by Redis).

A global aggregation must consume all matching documents before returning its result. WITHCURSOR COUNT batches the output; it does not split that global computation into separate commands. Without query workers, long-running aggregations can delay other Redis commands even when the queries use different connections. Increasing redisearch.scan-connections does not eliminate that server-side contention.

For mixed analytical and latency-sensitive workloads, evaluate Redis Software query performance factor. A local issue #115 experiment with Software 8.2.0-78.18 (Redis/Search 8.6) found that the 2x factor configured three query workers and reduced lookup latency during two concurrent aggregations. The 4x factor configured six workers but did not improve that experiment further. For an initial 2x evaluation on Redis Software 8.x, set the database’s REST API query_performance_factor field to:

Worker counts consume CPU capacity and can add overhead to individual queries, so measure your own workloads before choosing a factor. Redis Open Source exposes search-workers; the Enterprise measurements do not establish an optimal value for an Open Source deployment.

When query workers are unavailable, or their overhead is unsuitable, disable aggregation pushdown in the catalog:

Trino then computes aggregates from cursor batches, while Redis still applies supported filters. Disabling pushdown transfers more rows and can make aggregations substantially slower, but lets Redis process cursor batches between other commands. Aggregation pushdown remains enabled by default. Keep redisearch.scan-connections=4 and redisearch.cursor-count=1000 as the starting point and compare configurations with the benchmark rather than assuming more connections or smaller batches will help. See the experiment report for the configurations, timing variability, reproduction command and raw samples.