K3 · the data layer

One copy of your data. Every way to ask it.

Postgres SQL, vector search, graph traversal and S3 files, all on the same rows. Write once: your next query sees it, and search and graph read from the same copy. No sync jobs, no second database, no drift.

Start free dodil data connect my-bucket

Speaks Postgres: SQLAlchemy, Django, Prisma, GORM and more work out of the box · free to start, no card

acme · one bucket · one copy

SELECT id, vendor, total
  FROM invoices WHERE id = 42;

id	vendor	total
42	Globex	3,200.00

Postgres wire · psql, SQLAlchemy, any driver

Why we built our own database

Agents now build the software. And they need to remember.

The databases we had were made for people writing code by hand, one job each. An agent does two jobs at once: it builds systems for you, and it keeps its own memory while it works. K3 is one engine built for both.

agent → builds on K3

When an agent builds your system

It needs a database that catches its mistakes and grows with the business it builds.

Constraints and real types refuse bad data loudly, with a code the agent can act on

Transactions land a whole change or none of it

Writes are safe before they are confirmed, and a table can be rolled back

The same rows carry the app from its first user to its millionth

On the roadmapAgents work on a branch, a person approves, one click undoes it

agent → remembers in K3

When an agent needs a memory

It needs to remember by meaning, relate by graph and recall facts exactly, in one place.

Vectors for what it learned, rows for what is true, a graph for who relates to whom

It reads what it just wrote, with no lag between saving and finding

One connection and one set of keys, with limits you set per bucket

Files it is given become rows and vectors on upload

On the roadmapThe agent wakes when an answer it asked about changes

One copy, not four

No sync pipelines between a database, a vector store, a graph and a bucket. Less to store, less to move, less to pay for.

Our engine, end to end

We own the write path, the storage and the servers it runs on, in the UK with the EU next. No outside engine sets our roadmap or our price.

Built to grow with us

Every improvement lands across SQL, vector, graph and objects at once, for every customer, in one release.

The stack you stop running

Four databases to store one fact. Or one.

An app that searches, relates and stores files usually runs four systems and the jobs that copy data between them. Every copy is a chance to be wrong. K3 keeps one copy and answers every way.

Postgresyour records

A vector databasesearch by meaning

A graph databaserelationships

An object storefiles

Sync jobs between themthe part that breaks

5 systems · 4 copies · 1 source of drift

How it works

One copy underneath. Four doors on top.

Postgres SQL

Real types, primary and foreign keys, CHECK constraints and multi-table transactions. Your ORM and BI tools connect as they are.

Vector search

A vector is a column. Search it with pgvector operators, filter with WHERE, join the result like any other rows.

Graph

CREATE GRAPH over two tables you already have. Traverse with Cypher, or as a subquery inside SQL.

S3 objects

Files live in the same bucket. Point any S3 client at it, and turn uploads into rows and vectors with a pipeline.

ORM friendly

Your ORM already speaks K3.

K3 speaks the Postgres wire, so the models, sessions and queries you already wrote run unchanged. Point the connection string at your bucket and ship. Vector search and graph traversal come along on the same connection.

engine = create_engine(
  "postgresql+psycopg://…@pg.uk-lon-1.dodil.io:5432/shop"
)
Base.metadata.create_all(engine)

with Session(engine) as s:
    s.add(Order(id=1001, region="UK", amount=249))
    s.commit()

The database name is your bucket. Credentials come from dodil data connect.

Speaks Postgres. Your ORM just works.

Work out of the box, tested by a conformance suite

SQLAlchemyDjangoAlembicPrismaGORMSQLxpsycopgnode-postgres

Plus the standard Postgres drivers: pgx, pgJDBC, asyncpg, Npgsql.

A system of record

Run your ledger on it. Then search it.

K3 is not a lake you copy data into after the fact. It is where the data lives: the same rows your app writes are the rows your search, graph and reports read.

Durable before it says yes

A write is acknowledged only once it is on a replicated log in object storage.

All or nothing, across tables

BEGIN…COMMIT lands every statement together as one write, or none of them.

No lost updates

Two writers on one row resolve to exactly one winner, and the other is told to retry.

Types that mean it

DECIMAL to 38 digits, real UUIDs, enforced VARCHAR(n) and comparison CHECKs. Bad data is refused, never trimmed.

Your next query sees it

SQL reads always include your own writes, even inside an open transaction. No replica lag to design around.

Roll a table back

RESTORE TABLE to any version or timestamp in the last 7 days. The restore itself is versioned.

transfer.sql · Postgres wire

BEGIN;
SELECT balance FROM accounts
 WHERE id IN (:from, :to) FOR UPDATE;
UPDATE accounts SET balance = balance - :amt WHERE id = :from;
UPDATE accounts SET balance = balance + :amt WHERE id = :to;
INSERT INTO ledger (txn, account, delta) VALUES
  (:txn, :from, -:amt), (:txn, :to, :amt);
SELECT sum(delta) FROM ledger WHERE txn = :txn;  -- 0
COMMIT;

COMMIT · both legs landed together

2.7× faster

durable, replicated writes than CockroachDB on the same hardware

	K3	CockroachDB
Single-row INSERT	7.6 ms	20.5 ms

p50 server time per statement, one client, same machine. K3 0.2.4 against CockroachDB v24 with three replicas. Every K3 write is on a replicated quorum log before it is acknowledged. October 2026 benchmark.

Vector search Preview

Search by meaning, on the rows you already trust.

No second store to feed. Add a VECTOR column, index it, and filter, join and sort the results with the SQL you already write.

≥ 0.987recall@10 with hnsw_sq_f16, from 20k to 200k vectors

Exact distances

Indexes pick the candidates. Every result is re-ranked at full precision, so the distance you see is the true one.

Nothing silently lost

Every build proves every stored vector reachable, or it fails and tells you. A quietly lossy index can’t exist.

Searchable when saved

A vector is a row. The moment the write is acknowledged, a search can find it.

Five index kinds

HNSW, IVF and their quantized variants, picked per column with plain CREATE INDEX.

CREATE TABLE docs (id BIGINT PRIMARY KEY, body VARCHAR, embedding VECTOR(1024));
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

SELECT id, body FROM docs
 WHERE team = 'legal'
 ORDER BY embedding <=> :question LIMIT 5;

Keep your client

No new driver. Change the address.

One bucket answers on eight protocols your tools already speak. The bucket name is the database on every one, and dodil data connect prints them all.

PostgresSQL · vector · graph

pg.uk-lon-1.dodil.io:5432psql · psycopg · SQLAlchemy · SQLx · GORM · node-postgres

S3Objects

object.uk-lon-1.dodil.ioAWS CLI · boto3 · standard S3 SDKs

BoltGraph

bolt+s://bolt.uk-lon-1.dodil.io:7687Neo4j drivers · cypher-shell

HTTPTables

table.uk-lon-1.dodil.ioany HTTP client

gRPCTables

table-rpc.uk-lon-1.dodil.io:443dodil CLI · generated stubs · grpcurl

Qdrant APIPreview · Vector

qdrant.uk-lon-1.dodil.ioqdrant-client