SurrealDB 4 and SurrealDB Earth launched on 3 November 2026, on which you can build any kind of application: a SaaS product with a database per customer, a multi-model app at scale, or an AI agent with memory, serverless and isolated. A developer can give every agent or customer its own database that wakes on its first query and scales to zero, and recall by meaning, connection and exact words in one query.
Alongside SurrealQL and ISO GQL graph queries, SurrealDB 4 now also accepts PostgreSQL and MySQL clients over their own wire protocols.
Earth is now where every free SurrealDB Cloud account deploys, so there is nothing separate to sign up for: sign in to SurrealDB Cloud and you can create an Earth database straight away, on a free plan that needs no card.
The sections below cover what Earth does, how an agent recalls in one query, which PostgreSQL and MySQL statements SurrealDB 4 supports so far, and what we are building next.
What does Earth do that most serverless databases do not?
Earth is serverless SurrealDB on Cloudflare, built on Durable Objects and R2. Every agent, user or customer gets its own database, so one agent's data stays separate from another's.
| Property | What Earth does |
|---|---|
| Start | An instance wakes on its first query. Creating one takes about 500ms, and a cold start currently takes about 300ms. |
| Idle | An instance scales to zero when nothing is querying it. |
| Cost | You pay for requests and storage, with no idle server costs. |
| Scale | At peak, Earth reads 10+ billion rows per second, fully transactional. In our scale test, one query fanned out to around a thousand compute nodes that read object storage in parallel. |
| Writes | In the transactions film on the Earth page, load climbs from 1 to 100,000 transactions a second. Database cells are added at roughly 1,000 transactions a second each, then removed as load falls. |
The scale figures come from our own launch runs and films. Treat them as headline numbers for the launch deployment, not as a guarantee for every workload.
How does an agent recall in one query?
SurrealDB 4 runs a vector search, a full-text match, field filters and a graph traversal in one query, inside one transaction. The query below searches an agent's stored memories, each of which has a text, a kind, a date and an embedding, and follows graph edges from each memory to the people, projects and systems it mentions.
BEGIN;
-- The embedding of the agent's question
LET $q = [0.85, 0.15, 0.05];
SELECT
id,
text,
vector::distance::knn() AS distance,
-- The entities this memory mentions
->mentions->entity.name AS mentions,
-- Who owns what this memory mentions
->mentions->entity<-(relates_to WHERE label = 'owns')<-entity.name AS owners
FROM memory
WHERE embedding <|3,COSINE|> $q -- by meaning
AND text @@ 'migration' -- by words
AND kind = 'turn' -- by kind
AND said_at > d'2026-11-01T00:00:00Z' -- by time
ORDER BY distance;
COMMIT;The result of such a query looks like this: the memories that are close to the question, contain the word "migration", were spoken as a turn of the conversation and are dated after 1 November 2026.
[
{
"id": "memory:m1",
"text": "Ada said the ledger migration must finish before the invoice run on Friday",
"distance": 0.0037,
"mentions": ["Ledger migration", "Ada"],
"owners": ["Ada"]
},
{
"id": "memory:m4",
"text": "Postgres 14 reaches end of life so the ledger migration moves data first",
"distance": 0.0272,
"mentions": ["Postgres 14", "Ledger migration"],
"owners": ["Ada"]
}
]Each result says what the memory means, what was said and what it connects to. A memory that fails any one condition, such as a document passage instead of a turn, or a memory about something else entirely, is left out. SurrealDB Agent Memory is the managed way to use this pattern.
Which PostgreSQL and MySQL statements work today?
SurrealDB 4 accepts PostgreSQL and MySQL clients on native wire-protocol listeners. Each listener runs a defined subset of its dialect against the same tables SurrealQL uses. The table below shows which statements are supported in SurrealDB 4 and which are not yet.
| Works | Does not work yet |
|---|---|
JOIN, GROUP BY, HAVING, DISTINCT, UNION | ARRAY[...] constructor |
Non-recursive CTEs with WITH | WITH RECURSIVE |
row_number() OVER (ORDER BY ...) | CREATE FUNCTION, CREATE TRIGGER, CREATE ROLE |
jsonb and the ->> operator | GRANT, LISTEN |
BEGIN, ROLLBACK, COMMIT | FETCH FIRST n ROWS ONLY, so use LIMIT |
pgvector vector(n), hnsw index and <-> | LATERAL correlation |
Bound parameters with $1 on PostgreSQL | MySQL CREATE PROCEDURE and CREATE USER |
ROW_COUNT() and LAST_INSERT_ID() return 0 after a write on the MySQL listener. A statement outside the subset returns an error.
Our goal is 100% parity with both dialects and both wire protocols, and each release will move closer to it. The PostgreSQL and MySQL protocol references list what each release supports.
What are we still building?
Besides full PostgreSQL and MySQL parity, we are working on three things:
Database branching. Branching is coming to both Earth and Cloud Cluster, with R2 doing much of the work on Earth.
Faster cold starts. Earth cold starts currently take about 300ms, and we are working to bring that down.
Programmatic database creation. Earth is built for thousands of databases that agents and users create as they need them. We are designing how you create them from code.
What is the licence?
SurrealDB 4 is source available under the Business Source License 1.1. The licence permits any use except offering SurrealDB as a database service to third parties.
The licence converts to Apache License 2.0 on 3 November 2030. SurrealDB is not open source under the Open Source Definition today.
