One database, several ways to ask

Atomicity keeps a graph change and its related vector, payload, or observation in the same commit. Consistency applies schema, index, authorization, and conflict checks before publication. Isolation gives each read a pinned published version. Durability records an accepted commit in the WAL before the server reports it durable.

The useful consequence is simple: an application does not have to repair the interval in which a node exists but its embedding does not, or a geospatial observation appears without the entity update that explains it.

Readers pin a published version for the duration of a request. Concurrent writers can prepare later versions without changing the state already visible to that query. Graph expansion, vector filtering, key lookup, and geospatial selection therefore agree on the same publication boundary.

Versioning also gives recovery and replication a precise order. A replica can reject stale work, recognize a repeated apply, and resume from a known durable point instead of guessing which index moved first.

ShrikeDB appends transaction records to its write-ahead log, groups compatible durability work, and publishes only after the required flush completes. On restart, recovery replays committed records in order and reconstructs the published state and its derived access paths.

Checksummed records, commit identities, and replay-safe operations make recovery repeatable. The design keeps durable bytes sequential while allowing index preparation and post-commit work to use parallel hardware.

A storage flush can make several transaction records durable at once. ShrikeDB's native storage replay supports bounded groups of admitted independent transactions. Each member keeps its own log record, commit identity, and recovery receipt. Sharing the flush reduces repeated storage work without turning separate application changes into one transaction.

Recovery advances through a complete durable log prefix. A later completed write cannot hide an earlier unfinished one. Once grouped commit owns the work, it continues through durability and publication even if its caller disconnects; orderly shutdown waits for that work to finish.

This grouping currently serves the native storage replay path. Public HA request batching remains a separate integration step. The HA guide explains recovery and application retry behavior.

For HA-covered operations, a coordinator prepares the participating replicas, records the commit decision through quorum, and applies that decision idempotently. Durable receipts let repair distinguish a transaction that never committed from one whose decision survived while a replica was unavailable.

Write forwarding routes supported operations to the responsible leader. Replica apply uses the transaction identity and version to make retries safe. Read routing observes the published version required by the request.

Configure and operate an HA cluster or review transactions and snapshot behavior.

An entity UID connects its graph vertex, embedding, key–value payload, and geospatial observations. A vector result can start a graph pattern; a place-and-time result can lead to stored relationships. Each modality keeps an access path suited to its work while the application keeps one identity and one publication history.

This matters most in compound queries. “Find semantically similar reports from suppliers connected to this account during the affected interval” should not require three databases, an identity reconciliation job, and a prayer offered to the cache invalidation gods.

ShrikeDB imports Turtle, RDF/XML, and OWL sources as queryable RDF facts. Optional Rust-native materialization computes supported class, property, equality, restriction, and role inferences before publication. SPARQL can query the resulting ontology graph directly; bounded ontology functions let Cypher test subclass, reachability, ancestor, descendant, and path relationships against the same graph snapshot.

Semantic profiles connect application labels and fields to ontology concepts. Query results can retain the grounding path that justified a class match, which gives an analyst evidence to inspect instead of a category that appeared by administrative magic.

Import and query an ontology or review semantic profiles and ontology bindings.

Co-location, repeated visits, shared counterparties, and other correlations depend on parameters chosen for the investigation. Cypher can return the matching entities and evidence as rows. SPARQL CONSTRUCT can return a result graph. An application can inspect that result before deciding whether any relationship belongs in durable state.

See the query-time graph example and a place-and-time conjunction.

Register local Parquet and publish a reviewed mapping of source columns to graph concepts. Supported Cypher, SPARQL, HTTP, and MCP source queries project needed columns and apply bounded predicates against the registered files. The files remain authoritative, so exploration does not begin with another ingestion pipeline.

The mapping still defines identity, grain, and relationship meaning. Removing ETL removes a copy. It does not remove the data model. Connect a Parquet source.

Graph plans expose operator work through EXPLAIN and PROFILE. SQL, Cypher, and SPARQL share physical services rather than maintaining language-specific copies. Source-backed responses identify the selected mapping and scan work. Transaction and HA diagnostics identify the database, version, decision, and recovery state needed to operate the system.