// HACKER NEWS — CYBERSECURITY
BriskDB
BriskDB turns ordinary SQLite files into one database with parallel writes,
PostgreSQL compatibility, HTTP access, and embedded Rust/Python APIs. It keeps
SQLite's proven storage engine and tooling; BriskDB adds the routing layer,
shard-safe IDs, cross-shard indexes, protocols, and operational guardrails.
Try it without a compiler ·
Download an alpha ·
Open the data browser ·
Follow MongoDB and MySQL
BriskDB is an alpha, not a production-ready database service. The
boundaries are explicit, and measured results are
published even when they are not flattering.
The protocol adapters do not own database semantics. Routing, limits,
cancellation, values, sessions, and execution live in the shared Rust engine,
leaving room for more protocols and storage adapters later.
BriskDB serves a responsive, read-only data browser at /admin. It uses the
same bounded HTTP engine paths as other clients, combines sharded rows into one
logical view, reads global tables once, and preserves large integer values.
The temporary credentials are a development convenience—not a security
boundary—which is why the server currently refuses non-loopback HTTP addresses.
BriskDB has two generated-ID designs for sharded tables:
Both policies are versioned in the manifest. Generated-key execution is still
experimental and opt-in; the exact contract lives in
Generated keys.
These projects solve different problems. This table is a compass, not a
benchmark scoreboard.
Choose BriskDB when you want one local service or embedded engine to spread
write contention across inspectable SQLite files while speaking familiar
database protocols. Choose the others when a single SQLite file, replicated
high availability, managed edge sync, or a mature multi-node PostgreSQL cluster
is the real requirement.