QKeyDB Standalone — one file, one app

Meet QKeyDB

The database your team can carry. One .qkey file contains your schema, data, and the rules QKeyDB uses to interpret them, so the same database behaves the same on a laptop, a server, or an air-gapped lab machine.

Meet QKey Format
QKeyDB Query Console

.qkey for review, .qkb for speed—same engine

Human-readable QKey and versioned QKB binary

Use .qkey when humans need to author, diff, and approve schemas and contracts. Switch to compact .qkb when scans and throughput matter—binary storage stays compatibility-aware so upgrades stay predictable.

Multiple logical databases in one artifact

Carry separate databases inside a single portable container when domains should stay isolated but deployment should stay simple—fewer scattered files while preserving clear boundaries.

Contracts stay next to the data

First-class comments plus declarative @schema, @version, and @fields keep intent visible from pull request through production—the same artifact behaves the same on laptops, servers, or air-gapped hosts.

QKey Converter & interchange—built into the platform

Formats teams already use

Move data through JSON, CSV, XML, readable QKey, and binary QKB using the same import, export, and convert workflows—no separate “integration SKU.”

Public converter for integrations

Lightweight text/binary parsing and stringify paths suit browsers and glue services—ideal when partners only need dependable encode/decode at the edge.

Standalone depth when artifacts grow

Packaged deployments add streaming conversion, comment-preserving round trips, custom format hooks, and richer typed values—built for heavier pipelines without abandoning the same mental model.

Security & indexing that scale with the workload

Key-and-role ACL—deny-by-default posture

Authorize services with keys and scoped roles—not bolt-on DB users stapled late. Stage from permissive wiring through audit coverage into enforced deny-by-default policies backed by policy artifacts and HMAC material.

LivingIndex plus relational indexes

An in-memory LivingIndex keeps reads fast while durability stays append-oriented and checkpoint-aware; add ordinary secondary indexes first when SQL paths repeat—visibility tools show replay pressure when artifacts grow.

VH1 when retrieval goes semantic

VH1 adds advanced vector indexing for embedding-style search inside the same single-file durability story—reach for it once relational indexes stop matching the question, not on day one.

Standalone ops—with QKeyCluster when you graduate

CLI, Admin UI, SQL—and guided NLQ

Use precision SQL where it matters and natural-language helpers where accessibility wins—every surface routes through the same predictable artifact model.

Backup, restore, and evidence workflows

Lifecycle commands stay inside the file discipline—checkpoint-aware startup and governance presets keep regulated teams oriented without bespoke tooling.

Standalone Pro & .QKeyCluster.qkey

Cluster editions separate data artifacts from control-plane facts: topology, trust material, routing and sharding, observer promotion, fencing, conflict visibility, CA bootstrap, and rebalance planning live in the cluster file while datasets remain portable.

Launch QKeyDB

Portable artifacts, proven interchange, ACL-first security, indexing that grows with you—and a cluster story when multi-node reality hits.