We've made every effort to provide a robust querying interface, but there are some temporary limitations that we think you should know about. We aim to remove the limitations over the next few releases which we expect should happen fairly quickly.
Skytable's limitations primarily come from a bunch of concerns:
- Performance and scalability: Most of our design decisions are influenced by concerns about performance. For example, it's very hard to efficiently scale multi-column indexes.
- Reliability: how reliable is the execution of the task? If it's like walking on eggshells, then we're not going to implement it (for example, unreliable distributed locking)
- Security: If it can't be run securely, then it's off our list
- DML in collections are still limited: You'll be able to easily
INSERTdata into any collections but the manipulations on them are currently limited.:
SELECTwill return the entire collection and cannot yet return a single element
UPDATEcan append elements to non-nested collections but can't do the same for nested collections
DELETEcan't remove individual elements
- Models cannot be
volatileyet. If you've used Skytable before, you'd know that you could previously create
volatilemodels which were used as caching tables as in they didn't persist data across restarts. The
volatilefeature has been temporarily removed because we're working on integrating it with the new storage engine.
We understand that collections are fundamental to the complexity of today's data and hence we're working on this! The only reason our team spends so much time perfecting features is because it has match our design philosophy.
You can have 100 fancy but slow features, or 10 powerful and performant features.
If it scales, we ship it. We're on it!
Following Skytable's design philosophy that closely encompasses NoSQL systems, the following soft limitations are set:
- Only one index: Right now, the only index that you can use is the primary index (primary_key -> row). This is due to concerns about performance and scale
- No mass updates: We consider mass updates, such as setting
counter += 1to every row in a model with multi-million rows to be very slow and bad for performance. Hence, we do not allow mass updates at this time.