Build the database that’s right for you.
retrieval = engine(relational, standalone, full-text + vector, json)
Pick where your data lives, how it runs, how it indexes, and how you ask. Each one is a setting on the same table, not a separate system.
Data engine
Where your data lives. A table can be relational, a document collection, or a view over storage you already own, and the rest of the engine treats them the same.
- Relational
- Tables with a schema, joins, and constraints, the way Postgres taught you.
- Document
- Schemaless JSON, stored as it arrives. A mapping says what each field can do.
- Remote
- Buckets and lakehouse tables, queried where they already live.
Storage engine
How it runs. The API is the same in every shape, and a table moves between them with a backup and a restore.
- Lite
- One file an application opens directly, with no server. Embeds in Go and Zig, and the file restores into a server later.
- Standalone
- One node with everything included. Free, and where the quickstart runs.
- Distributed
- A Raft-replicated, sharded cluster. Shards split online as they grow.
- Serverless
- Compute over object storage, sized up and down by the Kubernetes operator.
- Antfly Cloud
- Hosted instances, with inference credits included.
Indexing engine
How it indexes. A mapping says what each field can do: searched, filtered, sorted, aggregated, or embedded by a model you name. Write a document and the engine chunks it, runs the embedder, and updates each index that covers it. Adding an index is one entry in the mapping, filled from the documents already in the table, with no second store to keep in sync.
- Full-text
- BM25 and phrase queries over analyzed text fields. Every table gets one by default.
- Dense vector
- Nearest-neighbor search over embeddings the engine computes at write time.
- Sparse vector
- SPLADE learned sparse retrieval alongside BM25.
- Graph
- Neighbors, paths, and match pattern queries over document relationships.
- Algebraic
- Sums, mins, counts, exact filters, and sort over typed values, without parsing stored JSON on the hot path.
Query engine
How you ask. The same tables answer JSON over HTTP and SQL over the Postgres wire, so the query language is a choice per client, not per database.
- JSON over HTTP
- One request hits every index at once, and each hit carries its score from each index that matched it.
- SQL over the Postgres wire
- psql and any Postgres driver connect without an adapter.
- DDL
- Create and alter tables and indexes from SQL.
- Joins and CTEs
- Across tables, including foreign tables, with filter pushdown.
- Window functions
- rank, row_number, and running aggregates.
- RETURNING
- Read back the rows a write produced.
- Sessions
- SET search_path and per-session state for tools that expect a schema.
- Document SQL
- A dialect over JSON tables; a table with no schema still takes a SELECT.