What is karma.run?
karma.run, also known simply as karma, is a data storage server.
- Strict data structure validation
- Powerful query engine
- Language and protocol agnostic
- Relation Graph
- Flexible ABAC permission model
- Continuous migrations
- ACID compliance
Data Structures & Validation
karma has a strong and powerful type system. Just like SQL, it supports a variety of primitive data types. Furthermore, karma.run goes beyond tables and rows by enabling you to define nested object structures, even recursive ones.
Unlike other database systems, karma.run's query engine does not follow the traditional model of parsing, planning and executing a declarative query. In fact, karma doesn't even have an own query language.
karma.run instead has a virtual machine embedded in its storage engine. This means that you can write full-featured, complex programs that manipulate your data imperatively, performing complex tasks and have them run directly on your karma.run server(s).
Language and protocol agnostic
The karma virtual machine (KVM) can be addressed through karma's RPC interface. You send a program in your favorite transport format (e.g. JSON) and it will be type-checked, compiled and executed for you.
Currently, karma.run's RPC interface is reachable through HTTP(S) and raw TCP. WebSocket integration is planned and other protocols and transport formats may be supported in the future.
Relations exist in karma.run like in traditional RDBMS. However, the graph that these relations form is checked and can never be inconsistent. This ensures that it is impossible to ever end up with references to objects that don't exist anymore, or alternatively, creating references to stuff that doesn't exist.
Supporting relations in a database naturally creates a graph of interconnected objects. In traditional SQL-based systems this graph is entirely implicit in the sense that it is not considered to be a thing in its own right. It's there, but you can't do anything useful with it.
Checking foreign keys for integrity in SQL-based systems is an ad-hoc feature that only some implementations support. It's enough to forget to set the constraint definition on a single table to jeopardize an entire relation-graph's integrity.
NoSQL databases normally don't support relations. Hence, graph-enabled NoSQL implementations lay a relation graph over their disconnected data sets. This enables the database user to create arbitrary (even senseless) relations between objects. If objects with relations cease to exist, their relations are also simply deleted.
In this sense, the graph in NoSQL systems is a neat added feature but not much more.
karma.run is relational like SQL but instead of foreign keys has a reference type (ref) that acts a bit like a pointer to a persisted object. The graph formed by the relations in your data set is automatically indexed when you write to karma and can be used to perform traversals and analysis. This graph helps you make sense of the interdependence of your data set and enables local-global view segregation.
ABAC (Attribute-Based Access Control) enables you to write rules that check attributes of data objects to decide if a certain user should be able to access the object in question.
In karma.run, you can write arbitrarily complex rules in the same format as you would write a program for an RPC call. The only condition is that they return a boolean value telling karma if permission is granted or not.
These rules can check simple properties or do complex logic at performance cost. Whatever you prefer. Your rules are then associated with roles (user groups), to which users belong.
One of the most powerful tools available in karma.run are continuous migrations. Rather than just adding or removing fields from a table or changing a field's value, karma's migration facility allows you to permanently connect two collections together by providing a mapping function between them.
For example, if you define a continuous migration from collection
c1 to collection
c2 through function
f, then writing an object
c1 will result in
f(o) being written into
Furthermore, you can connect two collections bidirectionally, i.e. migrate every write between them. This allows you to keep two different representations of a single object persistent. This in turn enables you to support legacy clients even long after initial release. It's also great for sharing anonymized data with partners.
The primary objective of karma.run is to make your data management sensible, consistent and integral. This is why karma scales horizontally without sacrificing consistency. Transactions work just like you'd expect, even in big distributed systems.