Live
One store · Seven views
Store it once.Read it every way.
One database for graph, SQL, documents, text search, vectors, time and audit — one store, one log, one program on your own hardware.
7
Views of one record
4
Query languages over one store
77
Graph algorithms in the engine
2
Time axes on every record
0
External services a query needs
3,893
Of 3,897 openCypher TCK scenarios pass
One store, seven views
Seven databases you'd normally run side by side. One store.
A graph database, a SQL database, a document store, a search engine, a vector store, something for history and an audit log — each with its own copy, and sync jobs holding them together. Here they are seven views of the same record, under one log.
One store, one log
One write. Every view sees it.
Insert a row with SQL and it is already in the graph, the search index and the history. No sync job and no second copy.
Origin and audit
Every write carries where it came from.
Who wrote it, through which door and from which load — and an audit trail that is hash-chained, so an edited entry is named.
What it solves
What running several databases costs you, and what changes.
Before
With Tessera DB
01
A graph database, a SQL database, a search engine and a vector store, with sync jobs holding them together.
One store. A write is in the graph, the tables, the search index and the history at once, with nothing to sync.
02
Nobody can say who changed a record, when, or through which system.
Every write carries its origin, and the audit trail is hash-chained, so an edited entry is named.
03
A regulator asks what the data said last March, and the old values were overwritten.
Every record keeps when it was true and when it was recorded, and SQL reads a table as of any moment.
04
Two APIs give two different answers to the same question.
SQL and Cypher read the same records and return the same rows. A sharded read is complete, or fails by name.
See it
The admin console, screen by screen.
06 SCREENS · CLICKTAP TO ENLARGE
Tessera DB
01 / 06
01
Dashboard
The database at a glance: records, types, writes, queries and branches.
See how many hyperedges and types the store holds, and how many writes and queries it has served.
Check health, storage mode and the active branch.
Load demo data, run a query or explore the graph from the quick actions.
How it works
Load it once. Read it every way.
A file goes in once, and every row becomes one record in one store, under one log — which the tables, the graph, full-text search, vector search and history all read, and SQL, Cypher or TQL all ask.
← Swipe for the whole diagram →
Why it's different
Why teams choose Tessera DB.
01
1
Record, many views
Write once. The graph, SQL rows, documents, text search, vectors and history all read that same record.
02
4
Facts on every write
Who made it, through which door, when, and from which load.
03
2
Time axes on every record
When it was true and when it was recorded. SQL reads a table as of any past moment.
04
#
Tamper-evident audit
Each entry is hash-chained and written before the change; a verify names an edited entry.
05
=
Exact answers
The same question gives the same rows on every door and in every language.
06
1
Store and one log
One write-ahead log and one transaction under every view. Nothing to sync.
07
0
Acknowledged writes lost
Of 1,000, with the process killed mid-write and every write synced. Measured, not derived.
08
Aa
Readable data
Any record reads back with its values as plain text, and BI tools read the rows over the Postgres wire.
09
1
Program, your hardware
One server binary. A query needs no external service: the embedder is built in.
Tessera DB is live
Start on the Free tier. A free binary and a free licence key.
Free
Free
one node, free licence key