Skip to content

Public Limits

The Online Playground deliberately exposes a narrower interface than a RadixDB server operated by an application owner. The boundary keeps the shared service responsive and prevents public requests from changing its dataset.

Each request must contain exactly one of the following:

  • a SELECT statement, including CTEs, subqueries, joins, aggregates, window functions and navigable references;
  • EXPLAIN SELECT ... without ANALYZE;
  • a SELECT entered in Explain mode, which the service wraps in EXPLAIN.

Write statements, DDL, CALL, PRAGMA, maintenance and administrative commands are rejected. Table-valued functions, query parameters, sleep and embed are not available in the public service. Policy is enforced from the parsed SQL tree, so words such as delete inside text, comments or column names are not mistaken for commands.

Boundary Limit
SQL text 8,192 bytes
Statements per request 1
Query deadline 5 seconds
Returned rows 200
Serialized response 1,048,576 bytes
Concurrent queries 1 globally and 1 per client address
Query starts 20 per minute per client address
HTTP request body 16 KiB

When more than 200 rows are available or the serialized response approaches its byte limit, the result is marked as truncated. Add a selective predicate and a stable ORDER BY with LIMIT when a particular slice is required.

The API connects with a dedicated principal that has only the permissions needed to read the published schema. The RadixDB TCP listener and the API listener are bound to loopback; nginx is the only public entry point. The synthetic dataset is treated as immutable and can be recreated from its verified generator artifact.

The SQL policy and database permissions are independent layers. A statement must pass both before it can read data.

A request exceeding five seconds returns a timeout. The API cancels the query, closes its database connection and releases the execution slot. Closing the browser request or selecting the cancel control follows the same lifecycle.

Cancellation is cooperative across the complete request path. The service does not promise that every query finishes successfully within the public deadline; instead, it promises a bounded public attempt and cleanup before later work uses the slot.

The result panel separates:

  • Execution: server execution until a result cursor is available;
  • Fetch: reading result batches through the native TCP client;
  • Total: API-side elapsed time including admission, connection, execution and fetch.

Browser rendering and the user’s network transfer are outside these engine/API figures. Cache state, host pressure and the single-query queue vary between runs. Use them to understand an individual live request, not to make a general RadixDB versus another database performance claim. Controlled comparisons and their hardware descriptions are in Benchmarks.

The Playground is a public demonstration hosted with the project website, not an SLA-backed database service. During maintenance it may reject or delay queries. The documentation, release archives and local quick demo remain the reproducible paths when the live service is unavailable.