Limits are for
the software
that can't think.

A database and a version control system, in one engine.

KDB holds three things under a single commit: whole JSON documents, returned exactly as you wrote them; opaque binary files — images, PDFs, archives — kept in a content-addressed blob store and described by a JSON metadata document you can query in SQL like any other; and the version history of both. One transaction writes the bytes, the metadata and the commit atomically, so a file and the record describing it cannot drift apart.

The database surface is a real one. Declare a schema and it becomes a typed, indexed lens over your documents — never a constraint on what they may contain — giving you KDB-SQL with joins, group-by, DML, DDL, views and GRANT/REVOKE, a JDBC driver for your existing ORM and BI tools, hash, B-tree, full-text and vector indexes, and stored procedures that run sandboxed inside the backend next to the data. Raw JSON stays reachable from inside the same query.

Underneath, every namespace is a repository: a content-addressed commit DAG with branches, tags, checkout and diff, covering documents, schema and files together. History is cheap because unchanged content is shared by hash — including blobs, so fifty versions of a document set with one large unchanged attachment cost one copy of that attachment. Peers are equal: they diverge for as long as they like and merge when they choose, and a conflict is surfaced to the application rather than silently resolved.

The entire engine compiles to the browser, the JVM and native binaries from one Kotlin Multiplatform codebase, with a parallel Go implementation kept honest by cross-language wire golden tests.

• Kotlin Multiplatform
• Go
• SQL & JDBC
• Stored procedures
• Binary attachments
• Git-like history
• Vector index
• AGPL-3.0

// JVM — JDBC, in-memory
Class.forName("dev.kdb.jdbc.KdbDriver");
Connection c = DriverManager.getConnection("jdbc:kdb:memory:///demo/users");

// Go — database/sql
db, _ := sql.Open("kdb", "kdb://memory:///demo/users?unique=true")

Early implementation — the spec, the engine and the tooling are public and moving.

Every rule lives in one place. A fast Go backend computes the whole game, and the clients just draw it.

Žolíky (Continental rummy), Prší (Czech Mau-Mau), Canasta and No-Limit Texas Hold'em run today on one runtime, one wire protocol, one screen client and one terminal client. Adding a fifth is a server-only change: register a module and it appears in the lobby, gets an opponent, gets a scoreboard, and is playable in a browser and over SSH without either client being edited.

The rules of each game live in exactly one file, on the server. The Go backend resolves every rule-derived fact — whose turn it is, which moves are legal, what a card may be played on, what the round scored — once per action, and sends the finished answer. Neither client carries a line of rule logic, so they cannot disagree with the server or with each other, and a rule can be corrected in one place and be right everywhere immediately.

Drag-and-drop shows what that buys. The client is never asked whether a card may go somewhere: the move it was handed already names the cards it takes and where they land, so the highlighted drop targets are just a filter over moves the server has already validated. No round trip, no guessing, no second copy of the rulebook — and it works the same way in every game, in both clients.

Every rule-derived fact is computed once, on the server, inside the module — and shipped.

• Go server
• React Native client
• Terminal client over SSH
• WebSocket protocol
• 4 games
• AGPL-3.0

Tell it what you want done, in ordinary words.

QTask is built around an AI agent rather than having had a chatbot added to it later. Agent sits in the header beside Projects and Tasks, and you talk to it the way you would talk to a colleague — create project Kitchen Reno, add tasks: Plan layout, Buy soil, Plant herbs, mark Schedule inspection as done. Compound requests work in one message, or step by step if you would rather approve each piece separately.

It proposes; you decide. Writes arrive as proposals in a pending-approval bar and change nothing until you approve them — reads just run, because there is nothing to approve about being told something. Turn on auto-approve when you would rather it got on with it.

Underneath is a real interface, not just a chat box: projects nesting under projects in a tree you can drag and reparent, tasks with nested subtasks and checklist steps, semantic search that finds work by meaning, and sharing with five roles — viewer, executor, editor, manager, owner — so you can watch shared work without being able to disturb it.

And the built-in agent is not the only way in: QTask ships an MCP server, so Claude Desktop or Cursor can work on the same projects and tasks directly, under the same approval rule.

• TypeScript
• AI agent
• Nested projects
• Shared roles
• MCP server
• Semantic search
• Self-hosted
• MIT