K3 Tables

The Postgres you don’t babysit. Transactions and analytics, one copy.

Real Postgres types, enforced constraints and multi-table transactions, with your reports reading the same rows your app just wrote. No replicas to tune, no warehouse to load, no servers to patch.

Start free dodil data pg -b my-bucket

Postgres wire · SQLAlchemy, Django, Prisma, GORM and more work out of the box

pg.uk-lon-1.dodil.io · shop

SELECT region, count(*) AS orders, sum(amount) AS revenue
  FROM orders
 WHERE placed > now() - INTERVAL '1 hour'
 GROUP BY region ORDER BY revenue DESC;

UK  142  8,419.20
EU   98  5,724.60
US   24  1,442.40

Bring your stack

Change the connection string. Keep everything else.

Models, sessions, RETURNING, optimistic locking: the code you already have runs as it is. A conformance suite runs real frameworks in Python, Go, Rust and Node against K3, so it keeps working.

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.

K3 Tables is where your data lives, not a copy you analyze later. The guarantees are the ones you’d expect from the database your money runs on.

Durable before it says yes

A write returns 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, with savepoints when you need them.

No lost updates

Two writers on one row resolve to exactly one winner. The other gets SQLSTATE 40001 and retries.

Types that mean it

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

Your next query sees it

SQL reads always include your own writes, including inside an open transaction.

Keys and constraints enforced

PRIMARY KEY, UNIQUE, CHECK and FOREIGN KEY on insert, plus SELECT … FOR UPDATE and savepoints.

2.7× faster

durable, replicated writes than CockroachDB on the same hardware

Single-row INSERTK3 7.6 msCockroachDB 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.

Analytics on live data

Your dashboard reads what your app just wrote.

No nightly export, no warehouse to load, no second copy that is always a little behind. Aggregations, joins, subqueries and CTEs run straight on the tables your app writes to, and any BI tool that speaks Postgres can read them.

App writes

INSERT … RETURNING

Same rows

no copy, no lag

Dashboard reads

GROUP BY · JOIN · CTE

WITH recent AS (
  SELECT * FROM orders WHERE placed > now() - INTERVAL '1 day'
)
SELECT c.segment, count(*) AS orders, avg(r.amount) AS basket
  FROM recent r JOIN customers c ON c.id = r.customer
 GROUP BY c.segment;

a bad deploy at 14:02

RESTORE TABLE orders
  TO TIMESTAMP AS OF '2026-10-29T14:00:00Z';

RESTORE · orders is back to 14:00, as a new version

Undo the bad day

Roll a table back to any moment this week.

Every table keeps at least seven days of history. Restore it to a version or a timestamp in one statement. The restore is itself a version, so you can always move forward again.

ComingTime travel in SQLSELECT any table as it was, right in the query.

ComingRestore to a new tableBring an old version back beside the live one, and UNDROP a table you removed.

Good to know