Metadata-Version: 2.4
Name: gnitz
Version: 0.1.4
Classifier: Development Status :: 2 - Pre-Alpha
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Rust
Classifier: Programming Language :: Python :: 3.14
Classifier: Programming Language :: Python :: Implementation :: CPython
Classifier: Topic :: Database
Classifier: Typing :: Typed
Requires-Dist: pytest>=8.0 ; extra == 'dev'
Requires-Dist: pytest-asyncio>=0.24 ; extra == 'dev'
Requires-Dist: mypy>=1.18 ; extra == 'dev'
Requires-Dist: maturin>=1.0,<2.0 ; extra == 'dev'
Requires-Dist: jupyterlab>=4.0 ; extra == 'dev'
Provides-Extra: dev
License-File: LICENSE-APACHE
License-File: LICENSE-MIT
Summary: Client for Gnitz, a SQL database whose views are all materialized and incrementally updated
Keywords: database,sql,dbsp,incremental,materialized-views
Author: Christian Schramm
License-Expression: MIT OR Apache-2.0
Requires-Python: >=3.14
Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM
Project-URL: Repository, https://github.com/Ed-von-Schleck/gnitz

# Gnitz

`Gnitz` is a SQL database. What makes it different from most other SQL databases is that `VIEW`s are all _materialized and incrementally updated_, meaning: They never go stale, and they are updated _efficiently_ – the cost to update a `VIEW` is always proportional to the size of the _changed_ data, regardless of how much _existing_ data there is. It intentionally restricts `SELECT` statements to the bare minimum so that queries are _always fast, no footguns_. `Gnitz` spills these `VIEW`s to disk, so it trades disk-space for latency.

A Gnitz guarantees efficient `VIEW` updates by implementing the **DBSP** (Differential Dataflow) formal model, treating all data as **Z-Sets** – multisets where every record has an associated integer weight, enabling algebraic coalescing of updates.

