What is AetheriusDB?
AetheriusDB is a high-performance database that serves SQL, vector search, graph traversal, and AI workloads from one engine — and lets you run your own logic inside the database as WASM compute cells, instead of shipping rows out to an application server.
One database, several query styles
Section titled “One database, several query styles”Most stacks bolt together a relational database, a vector store, a graph database, and a temporal/audit store. AetheriusDB serves all of those over the same data:
- Relational SQL — strictly typed tables and a broad ANSI SQL surface.
- Vector search — native fixed-dimension
TENSOR(n)columns with HNSW and IVFFLAT indexes for k-nearest-neighbour queries. - Graph traversal — relationships are followed by direct link hops, not rebuilt with join tables on every query.
- Time-travel — query a table as of an earlier point in time, and replay history.
You don’t choose between a SQL database, a vector store, and a graph store — they are different views over the same tables.
Move logic to the data
Section titled “Move logic to the data”Instead of an application server that pulls rows over the network and reshapes them, you can deploy a small WASM compute cell into the database. The cell runs next to the data and returns only the final result — turning many round-trips and serialization passes into a single call.
flowchart LR
classDef wire fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
classDef core fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
classDef store fill:#0d1322,stroke:#4ade80,color:#e8eaf0
subgraph Wires["Connect over any protocol"]
W1[Native client]:::wire
W2[PostgreSQL pgwire]:::wire
W3[Arrow Flight SQL]:::wire
end
subgraph Engine["One engine"]
Q[SQL planner]:::core
C[WASM compute cells]:::core
end
subgraph Data["One set of tables"]
S1[Relational + vector + graph + temporal]:::store
end
Wires --> Engine --> Data
Who it’s for
Section titled “Who it’s for”| If you build… | AetheriusDB gives you… |
|---|---|
| An AI / RAG app needing SQL + vector + graph in one query | Native tensor columns, kNN indexes, and link traversal in one engine |
| A real-time analytics pipeline ingesting millions of rows/sec | A high-throughput bulk-ingest path that projects raw bytes straight into columns |
| A multi-tenant SaaS with row-level security on every query | RLS predicates compiled into the query plan |
| An edge / IoT fleet with intermittent connectivity | Each node is a full database; changes reconcile when they reconnect |
| A team that wants “database-as-code” | Branchable schemas, a time-travel debugger, and deterministic test runs |
| A mixed workload: short writes next to long analytical scans | HTAP — writes land in a fast mutable tier with snapshot isolation, and are merged into optimized columnar storage in the background |
What AetheriusDB is not
Section titled “What AetheriusDB is not”Availability note: HTAP
Section titled “Availability note: HTAP”enable_htap = true · primary-key lookups use a fast-reject filter to skip scans HTAP (mixed transactional + analytical workloads on the same table) is implemented and enabled with a flag. When on, writes land in a mutable Delta tier with snapshot isolation and write-conflict detection, and queries read both the Delta and the sealed analytical tiers. See the configuration matrix for the exact flags and their defaults.