Oxla

Editor’s note: This Oxla review is based on my hands-on evaluation of the Oxla engine as Redpanda sells it today, Redpanda SQL on Redpanda BYOC (the server identifies itself as oxla version 1.0.0), in October 2026. I weighed pricing, setup, SQL compatibility, Iceberg querying, security, standalone Oxla’s fate and rivals.

Quick verdict: I recommend Oxla, in its Redpanda SQL form, for teams on Redpanda BYOC, or ready to move there, who want ad hoc Postgres-style SQL over live topics and Iceberg history. It is read-only, quote-priced and tied to Redpanda, so it replaces neither a warehouse nor the old self-hosted Oxla.

Redpanda acquired Oxla on October 28, 2025, and made its C++ MPP engine generally available as Redpanda SQL on May 27, 2026. In this review, I’ll take a closer look at Oxla’s pricing, features, and limits, so you can see exactly whether it fits.

Key Takeaways:

• Standalone Oxla is gone: oxla.com redirects to Redpanda SQL; the free Developer edition and $50 per core per month Enterprise license are discontinued.
• One Postgres-dialect query covers live topics and Iceberg history.
• Read-only: no INSERT, UPDATE, DELETE or materialized views.
• Priced per provisioned RPU-hour by quote, plus the cloud instance bill.
• BYOC on AWS and GCP only: self-managed is targeted for 2H of Redpanda’s fiscal 2027.

Pros and Cons

How Much Does Oxla Cost?

Redpanda SQL bills provisioned compute by the hour, not queries run: 1 RPU is 2 vCPU plus 8 GB of memory, each SQL node is 4 RPUs, and the minimum is one node. The meter runs while the engine is enabled, so idle hours bill too.

The per-RPU rate for SQL differs from the Redpanda Streaming rate and comes only from your account team. AWS or GCP bills each node’s instance separately, which makes the SQL quote one of three lines on the bill:

• Redpanda BYOC (annual commitment): The required base, with a 14-day trial on request. Redpanda’s plan card lists up to 2 GB/s writes, 4 GB/s reads and a 99.99% SLA; those are streaming figures, not SQL query guarantees. On AWS Marketplace, BYOC is sold only as a private offer.
• Redpanda SQL (per RPU-hour, quote only): Provisioned query compute for organizations on usage-based billing. Start at one node and add replicas, 4 RPUs each, when memory or concurrency runs short.
• Cloud instances (billed by AWS or GCP): Each 4-RPU node runs on an AWS m6i.2xlarge or a GCP n2-standard-8, which is 8 vCPU and 32 GB per node.
• Redpanda Serverless (free start, no card): The only self-serve Redpanda tier, but SQL is not on it: Redpanda SQL requires BYOC.

Redpanda’s BYOC sizing quotes include the SQL engine license at your organization’s rate card, so ask for one at your planned node count. Old Oxla priced in public: $0.06 per vCPU-hour self-hosted in 2024, then from $50 per core per month in 2025. Both offers are discontinued.

Offering	Price	Trial	Notes
Redpanda SQL on BYOC	Quote per RPU-hour, plus BYOC commitment and cloud instances	14-day BYOC trial by request	Usage-based billing organization required
Old Oxla Developer edition, discontinued	$0	None, no longer offered	Single node, Docker, non-commercial use
Old Oxla Enterprise, discontinued	From $50 per core per month (2025); $0.06 per vCPU-hour self-hosted (2024)	None, no longer offered	Historical prices, not current offers
MotherDuck Business	$250 per month plus usage	Free tier	Serverless DuckDB
ClickHouse Cloud	Compute from $0.2181 per unit-hour; storage $25.30 per TB-month	$300 credit for 30 days	US East rates; compute and storage billed separately

Is Oxla Good Value for Money?

• Good fit: Existing Redpanda BYOC customers. SQL becomes one more line on a contract you already have, and topic data reaches analysts without an ETL job into a warehouse.
• Less convincing fit: Teams not on Redpanda. You take on a streaming platform commitment to reach the SQL engine, before the RPU rate even enters the math.
• Budget priority: ClickHouse Cloud or MotherDuck, if procurement needs a number before a sales call. Both publish rates, though each still needs sizing.

Reviewer’s Notes: Start with the minimum single 4-RPU node during the 14-day BYOC trial, and get the SQL RPU rate in writing before you enable anything. Budget for enabled hours, not query time: an idle node bills while the engine is on, and the m6i.2xlarge or n2-standard-8 instance bills on top.

My Experience With Oxla

Enabling SQL on My BYOC Cluster

The SQL toggle needed two things first: an organization on usage-based billing and admin rights. On a new cluster, the Redpanda SQL engine card carried an RPU slider; on an existing one, I found it under Dataplane settings, Cluster tab, RP SQL row.

Provisioning can take up to 30 minutes. AWS BYOC clusters created before May 28, 2026 need rpk cloud byoc aws apply rerun first, and GCP clusters created before August 4, 2026 need the GCP equivalent. The Cloud API (rpsql.enabled, rpsql.replicas, rpsql.zones) and the Terraform provider do the same job.

Pick the zone before you click enable. SQL lands in a single availability zone, the cluster’s first zone by default, and that choice is locked at first enable.

Connecting With psql

I connected with psql 16 or later, with TLS required (sslmode=require), using the string from the SQL tab of the How-to-connect panel. The database name is still oxla, and the banner reported server 16.0 (oxla version: 1.0.0...): a Postgres 16.0 compatibility version and Oxla 1.0.0.

Redpanda SQL accepts 3 authentication modes:

• Bearer token: a short-lived token from rpk cloud auth token (rpk v26.1.6 or later), passed as options='auth_method=bearer'.
• Client credentials: auth_method=client_secret with a service account’s client ID and secret.
• SCRAM: a password set by a SQL: Manage user with ALTER USER, for legacy clients such as Power BI.

psql "host=<sql-host> port=5432 dbname=oxla sslmode=require options='auth_method=bearer'"

Mapping a Topic and Running My First Query

Enabling SQL created a catalog named default_redpanda_catalog, pointed at the cluster. In Redpanda SQL, CREATE TABLE maps a topic instead of creating storage:

CREATE TABLE default_redpanda_catalog=>orders
WITH (topic = 'orders', confluent_wire_protocol = 'false');

The schema came from Schema Registry: Avro, Protobuf or JSON, under the subject <topic>-value by default, with LATEST as the only lookup policy. I set confluent_wire_protocol = 'false' because records produced from the Console carry no wire-format prefix.

Every mapped table gained a redpanda struct column (partition, offset, timestamp, headers, key) and a redpanda_raw column. Under error_handling_policy = 'FILL_NULL', undecodable records stay queryable with their raw bytes; the other policies are FAIL (the default) and DROP_RECORD.

For browser work, SQL Studio (added July 2026) sits in the Cloud Console with autocomplete, query tabs, the last 40 queries kept in the browser, CSV and JSON export, and an Add-a-topic wizard. It runs read queries only.

Materialize and RisingWave make you define views up front; here, a SELECT on a mapped topic was the whole job.

Reviewer’s Notes: Register every topic’s schema before mapping it, and choose the SQL availability zone before you click enable. The zone never changes, and after a disable the catalog and grants do not carry over.

The Oxla Engine: Postgres Dialect, C++ MPP and Hard Limits

Oxla is not built on PostgreSQL. Redpanda SQL runs a C++ MPP engine that speaks the Postgres wire protocol natively, which is why psql, DBeaver, DataGrip and JDBC connect. It is semantically compatible with PostgreSQL, not code compatible.

SQL Features I Value

• Analytical syntax: inner, left, right and outer joins, UNION, INTERSECT, EXCEPT, CTEs and window functions, backed by 170 function pages in the SQL reference.
• Data types: array, json, map (since September 2026), uuid (since August 2026), timestamp with and without time zone, and geometry and geography for point values only. UUID columns need a ::text cast for string functions.
• Views: CREATE VIEW arrived in October 2026; a view re-runs its query on each read and runs with its owner’s privileges.
• Fast math: the oxla.enable_fast_math session switch trades precision for speed, so keep it off for financial figures.

Limits That Can Block a Migration

• Read-only: no INSERT, UPDATE, DELETE or upserts, and no materialized views yet.
• No transactions: BEGIN and COMMIT are accepted for client compatibility, but each query executes immediately.
• No extensions: pgvector, PostGIS and pg_cron are out, and prepared statements are translated back to strings.
• Field limits: 32 MB per variable-size field; array columns cannot be ORDER BY, GROUP BY or JOIN keys.
• Numeric: precision up to 76, but no arithmetic or aggregate functions.
• No spill to disk: joins, sorts and GROUP BY hash tables that outgrow cluster memory are cancelled with Query Out of Memory!. The fix is more nodes, less concurrency or a narrower query.
• Dialect gaps: LN(0) returns Infinity, pi() is unknown, SELECT DISTINCT ON is unsupported, and result headers read f, f_1.

The no-spill rule is the limit to size around first. ClickHouse accepts writes and updates; this engine only reads, and every join has to fit in cluster memory.

Oxla’s own performance figures come from a 2024 desktop run of the Star Schema Benchmark at scale 100: 2.75 seconds versus 182.23 seconds on PostgreSQL for an average-revenue query. On a highly selective filter, PostgreSQL’s index won, 11 ms against Oxla’s 416 ms.

The 2026 VLDB paper by co-founder Adam Szymanski and Redpanda CTO Tyler Akidau credits a ring-buffer shuffle, and itself calls the gains workload-shape-dependent. None of these numbers are my measurements.

• Best for: scan-heavy analytical queries over Redpanda topics and Iceberg history.
• Skip if: you need writes, Postgres extensions, or queries whose intermediate state must spill to disk.

Live Topics and Iceberg History in One Query

On an Iceberg-enabled topic, one SELECT returns live records plus Iceberg-committed history with no overlap and no UNION ALL. It also reaches records older than topic retention, as long as they were committed to Iceberg before they expired.

That is the strongest reason to buy for a Redpanda shop: a dashboard query crosses the live-to-history boundary without a warehouse-loading job in between.

What Iceberg Querying Requires

• An external REST catalog: one you provide, such as AWS Glue, GCP Lakehouse, Snowflake, Databricks Unity or Polaris, with the cluster’s iceberg_catalog_type set to rest. The object_storage type does not support SQL queries.
• Redpanda-written tables: only tables written by Redpanda Iceberg Topics. Iceberg tables populated by Spark or Flink are out of scope.
• REFRESH after schema changes: run REFRESH <catalog>=><table> after any shape change, or the next query fails at planning with Schema not found for Iceberg table. REFRESH updates the schema view, not the data.
• Supported nesting: a list of lists or a list of maps makes CREATE TABLE or REFRESH fail; lists of primitives and lists of structs work.

Once the REST catalog is set, Redpanda Cloud runs CREATE STORAGE, CREATE ICEBERG CATALOG and the ALTER REDPANDA CATALOG step for default_redpanda_catalog itself.

Where I Recommend Using It

• Topic debugging: Redpanda’s own example, below, pulls failed orders from the last 30 minutes instead of dumping a topic to files.
• Operational dashboards: the last few minutes and months of committed history in one table.
• Agent workloads: parallel, join-heavy SQL over streams and history, the agent-governance job Redpanda built the engine for.

SELECT *
FROM orders
WHERE status = 'failed'
  AND timestamp > NOW() - INTERVAL '30 minutes';

Confluent sells Tableflow and Flink SQL as separately billed products, Flink at $0.21 per CFU-hour list, and the Iceberg side still needs another query engine. Use Redpanda SQL for this combined query when Redpanda already owns ingestion, not as a reader for a multi-writer lakehouse that Spark or Flink also write to.

Security, Deployment and What Happened to Standalone Oxla

Access Control

Redpanda SQL has 2 data-plane roles:

• SQL: Manage: engine superuser; reads every topic, creates catalogs and tables, and grants access.
• SQL: Access: connects, but reads nothing until granted SELECT.

Access is deny-all by default. Grants name the user’s Redpanda Cloud email, and wildcards work only at the end of a pattern:

GRANT SELECT ON EXTERNAL SOURCE
default_redpanda_catalog => 'orders'
TO "alice@example.com";

Every query reaches the cluster through one internal SASL credential, so Kafka ACLs do not gate query-time access. GRANT and REVOKE are the only boundary between SQL users, whatever your topic ACLs say.

Deployment and Availability

Redpanda SQL has run on AWS BYOC since May 2026, and on GCP (BYOC and BYOVPC) and AWS BYOVPC since August 2026. Confirm your GCP region with Redpanda before you commit; Azure is waitlist-only, and self-managed is the 2H fiscal 2027 target covered below.

The engine sits in one availability zone even on a multi-AZ cluster, so do not read the BYOC 99.99% SLA as a multi-zone promise for SQL.

Disabling SQL wipes catalogs, table mappings, roles and grants, and in-flight queries fail. Topic data, Schema Registry subjects and Iceberg history stay; re-enabling provisions a fresh, empty engine.

If You Ran Oxla Before

The pre-acquisition Oxla was a self-hosted warehouse: Docker install, S3-compatible storage such as MinIO, multi-node deployment, and UPDATE and DELETE support. None of the write side carries into Redpanda SQL, and version numbers do not map either: the server reports oxla version 1.0.0, while the last public image was 1.76.0.

The last public Docker Hub tags, 1.76.0 and earlier, date from May 2025, and anonymous pulls are now refused. The old public ECR image no longer resolves, and no end-of-life notice or migration guide is publicly documented. Self-managed Redpanda SQL is targeted for the second half of Redpanda’s fiscal 2027.

Reviewer’s Notes: If separation between teams matters, model it in SQL GRANTs from day one. Topic ACLs protect nothing at query time here, because every query runs through the same internal credential.

How Does Oxla Compare to Competitors?

Redpanda SQL reads only Redpanda topics and their Iceberg history; every rival below ingests data from anywhere, and most publish a starting price.

Tool	Starting price	Model	Best at
Oxla / Redpanda SQL	Quote per RPU-hour, plus BYOC commitment and cloud instances	Read-only Postgres-dialect engine on Redpanda topics and Iceberg Topics	Ad hoc SQL on live streams inside your VPC
ClickHouse Cloud	Compute from $0.2181 per unit-hour; storage $25.30 per TB-month	Columnar OLAP	High-volume event analytics with writes and updates
StarRocks	Free open source; managed as PhoenixAI, quote only	MPP OLAP with lakehouse queries	Joins over Iceberg and Delta from any writer
Imply Polaris	Starter from $100 per month	Managed Apache Druid	Streaming ingestion into sub-second dashboards
RisingWave	From $0.227 per RWU-hour; 7-day trial	Postgres-compatible streaming database	Incremental materialized views
Materialize	$1.50 per compute credit-hour in select regions	Streaming SQL	Always-fresh views over CDC
Confluent Cloud Flink SQL	$0.21 per CFU-hour list, region-dependent	Stream processing on Kafka	Continuous transformations
MotherDuck	Business $250 per month plus usage	Serverless DuckDB	Cheap ad hoc analytics on loaded data

• Oxla vs ClickHouse: ClickHouse wins high-volume event analytics that needs ingestion, writes and updates, with Basic compute from $0.2181 and Scale from $0.2985 per unit-hour. Redpanda SQL wins only when the records already sit in Redpanda topics and a second copy is what you want to avoid.
• Oxla vs StarRocks: StarRocks fits Iceberg or Delta lakehouses with many writers, where joins span tables Redpanda never wrote. Its free open-source engine, or PhoenixAI Anywhere by quote, is also the self-managed route standalone Oxla no longer offers.
• Oxla vs Apache Druid and Imply: Druid on Imply Polaris suits always-on streaming dashboards over ingested data, and Standard runs from $600 a month with a 99.9% SLA. Polaris lists a $100 monthly Starter with a 25 GB cap; confirm the offer with Imply before budgeting on it.
• Oxla vs RisingWave and Materialize: Both keep results fresh through incremental materialized views, which suits repeat application queries; RisingWave runs hosted on AWS, GCP and Azure, and Materialize ships a free local Emulator image for testing. Redpanda SQL suits questions that change daily, with no view to define first.
• Oxla vs Confluent Flink SQL: Flink SQL runs continuous transformations on Kafka you already operate on Confluent. Confluent’s Kafka tiers start at $0 for Basic, and a Postgres endpoint alone does not justify migrating a Kafka platform to Redpanda.
• Oxla vs MotherDuck: MotherDuck is the cheaper ad hoc option for data you can load, at $250 a month plus usage and $0.043 per GB-month of storage. It does not read live topics, so it loses when the question is about the last few minutes of a stream.

An RPU, an RWU, a CFU and a compute credit measure different things, so compare full workload costs, including the cloud instance bill Redpanda SQL adds to its quote.

How I Reviewed Oxla

I worked through the documented Redpanda SQL setup on a BYOC cluster: enabling the engine, authenticating, mapping topics, querying live and Iceberg data, and SQL Studio. I also covered the SQL dialect and its differences from PostgreSQL, access control and deployment constraints, Redpanda’s billing model, and the pre-acquisition Oxla product and its pricing.

I compared it with ClickHouse, StarRocks, Imply, RisingWave, Materialize, Confluent and MotherDuck on price model, write support and the workloads each one wins. Oxla’s benchmark figures are the vendor’s own; I ran no benchmarks of my own, and I list old Oxla prices only as discontinued history, never as an offer you can buy today.

Prices current as of October 2026.

Should You Use Oxla for Real-Time Analytics?

Oxla’s engine is real, fast on scans by its own figures, and Postgres-friendly from psql to DataGrip. It now exists only as Redpanda SQL: read-only, BYOC-only and quote-priced, with a single-AZ engine that cancels queries it cannot fit in memory.

• Redpanda BYOC customers: Turn it on during the trial, at one 4-RPU node, if you debug topics or need ad hoc SQL over streams and Iceberg history.
• Kafka shops on Confluent or MSK: Moving platforms for a SQL engine is a big ask; look at Confluent Flink SQL or RisingWave first, which both publish per-hour rates.
• Teams who wanted standalone, self-hosted Oxla: Choose ClickHouse or StarRocks, since self-managed Redpanda SQL is only targeted for the second half of Redpanda’s fiscal 2027.
• Teams needing a price before a call: Shortlist ClickHouse Cloud or MotherDuck, which publish compute and storage rates up front.

My next step for a Redpanda shop: request the 14-day BYOC trial and the SQL RPU rate in the same email, starting from the Redpanda SQL page.

FAQs

What happened to Oxla?

Redpanda acquired Oxla on October 28, 2025. The engine became Redpanda SQL, generally available on May 27, 2026, and oxla.com now redirects to the Redpanda SQL page. The standalone Developer and Enterprise editions are discontinued, so today Oxla means a read-only query engine inside Redpanda BYOC on AWS or GCP.

Is Oxla open source?

No. Oxla was proprietary software. Its free Developer edition allowed single-node Docker installs for proofs of concept and non-commercial use, which never made the code open, and that edition is no longer offered. For an open-source, self-managed analytical engine, look at StarRocks or ClickHouse instead.

How much does Redpanda SQL cost?

Redpanda SQL bills per provisioned RPU-hour, at a rate your Redpanda account team quotes; no price is published, and it differs from the Redpanda Streaming rate. Add the BYOC annual commitment and the AWS or GCP instance bill. Each node is 4 RPUs (8 vCPU and 32 GB), and the meter runs while the engine is enabled, idle or not.

Can I still self-host Oxla?

Not with a supported download. The last public Docker Hub tags date from May 2025, anonymous pulls are refused, and the old public ECR image no longer resolves. Self-managed Redpanda SQL is targeted for the second half of Redpanda’s fiscal 2027, so plan around ClickHouse or StarRocks if you need self-hosting now. No end-of-life notice or migration guide is publicly documented.

Is Redpanda SQL compatible with PostgreSQL?

Partly. It speaks the Postgres wire protocol and a Postgres dialect, so psql 16 or later, DBeaver, DataGrip and JDBC connect. It is not PostgreSQL underneath: extensions such as pgvector and PostGIS are unsupported, it is read-only, and functions like LN(0) and pi() behave differently than in PostgreSQL.