- What is "Database Depth"?
- Is this just another NoSQL solution?
- Is there a complicated API?
- Is there anything to install?
- What are "free-form data structures" and does this help me as a web developer?
- I can create complex structures and relationships now. How is SchemafreeSQL different in this respect?
- What is "join-free SQL" and why is this a good thing?
- What is "unbounded, cross-relationship global querying"?
- Can large text attributes and BLOBs be stored?
- Is full-text search available?
- Are any MVCC-like operations available?
- What is meant by "Optimization-free"
- What is date math and date shortcuts?
It is impossible to know up-front the data structure that your web application will require, yet developers are asked to create data models in advance. Then, when changes are required to that model - and they always are for any 'living' application - the developer's database often becomes a chain that ties them to limited structure possibilities or difficult-to-change data structures. And on top of the structure limitations, there are inevitably limitations on the querying abilities provided by the same database.
Not true with SchemafreeSQL, wherein the web developer can immediately start saving data in any structure
and alter that structure at runtime without missing a beat.
SchemafreeSQL also allows Web developers to fearlessly query their data without limitations
and often in manners never thought possible.
Complex ad-hoc queries can be created at runtime without the need to manage indexes
and without the need to develop inefficient methods that require layers of back-and-forth trips to the database.
SchemafreeSQL scores high in both Data Structure Flexibility and Querying Ability, giving it a high Database Depth score compared to other database solutions.

- NOT a pure SQL database SchemafreeSQL eliminates the need to define zombie schemas and indexes and write JOINs.
- NOT a document-based database
Several document-based database systems claim to be schemaless, yet when your data demands cross-document relations (esp. many-to-many), something ugly rears its head which usually ends with you performing multiple queries and relating (or JOINing) data by hand. This essentially forces the work away from the locality and fast speed of the database level, and up towards the remote and slow speed of the client-to-database connection. The difference in speed is akin to the difference between registers and RAM, or between RAM and Disk.
The resultant design pattern often ends up a mirror of what you would have done in any standard SQL database, but without the low level optimizations that a SQL database brings to such a pattern.
Additionally, with a non-native design pattern now in place to deal with your data relationships, concurrency issues may begin to surface.
In SchemafreeSQL, your data relationship possibilities are essentially unbounded; yet consistent in both design patterns, access patterns and performance. - NOT a key-value database At the simplest level, SchemafreeSQL allows arbitrary key-value relationships just as key-value stores do, but SchemafreeSQL also allows the values to be objects themselves (no need for embedded 'lists') and provides powerful-yet-simple querying via SFQL.
- NOT a SQL-layer on top of a map-reduce database SchemafreeSQL data relationships are handled at the database level. Map-reduce SQL layers are implemented at higher and much slower levels.
- NOT a ORM-layer SchemafreeSQL data objects, although represented with the simplicity of ORM-styled dot-notated relationships, are completely independent of your programs' in-memory objects. Object-Relation-Mapping layers, on the other hand, create an impedance-mismatch between in-memory objects and database objects.
- NOT a vector-based database Although powerful, navigating vector-based databases can become complcated. SchemafreeSQL's simple-yet-powerful SFQL delivers consistent developer productivity.
Language-specific APIs which implement the JSON API can be implemented. We have developed a reference version of such an API in go which is freely available for inspection and use.
The core JSON itself is very simple and extensible, leaving room for future SchemafreeSQL features without disturbing the core API JSON structure.
With SchemafreeSQL, you can query deeply across complex structures via a simple join-free SQL syntax called SFQL (Schema-Free Query Language).
Example:
The above query and structure naturally supports cases of both one-to-one, one-to-many and many-to-many relationships (e.g. companies to persons, or persons to addresses) without requiring extra lookup tables for the many-to-many relationships. This simplicity gives you new efficiencies when working with complex or deep data strutures, thus increasing your overall productivity as a developer.
FROM company
INNER JOIN person ON person.companyId = company.id
INNER JOIN address ON address.id = person.addressId
WHERE address.city='Rochester' AND person.income>50000
And if the address-to-person relationship was a many-to-many (e.g. if you wanted to allow your structure to support persons who share a single address object without duplicating address objects - such as a husband and wife) then standard SQL would require:
FROM company
INNER JOIN person ON person.companyId = company.id
INNER JOIN personAddress ON personAddress.personId = person.id
INNER JOIN address ON address.id = personAddress.addressId
WHERE address.city='Rochester' AND person.income>50000
And if the person-to-company relationship was also a many-to-many (e.g. if you wanted to allow your structure to support people who work for multiple companies without duplicating person objects) then standard SQL would require:
FROM company
INNER JOIN companyPerson ON companyPerson.companyId = company.id
INNER JOIN person ON person.id = companyPerson.personId
INNER JOIN personAddress ON personAddress.personId = person.id
INNER JOIN address ON address.id = personAddress.addressId
WHERE address.city='Rochester' AND person.income>50000
Unbounded queries allow you to query outside the confines of your data structure and are an example of how SchemafreeSQL can "expand your application possibilities."
For instance, you can issue a unbounded query (SELECT $oid WHERE $s:city='Rochester') against a database that contains vendor.address.city objects and promotion.city objects and the query will return the oids of both matching vendor.address objects and matching promotion objects. This single query takes the place of what would normally require 2 queries (whether executed in series or with a UNION).
Additionally, SchemafreeSQL global queries can be optionally bounded to any select number of parents. For example you could globally query (WHERE $s:person.address.city) which would limit your query to person.address objects no matter where they occur in your database (e.g. under employees, or under family, etc.)
You can store as many blob and large-text attributes per object as you like. SchemafreeSQL does not place an extra constraint on the maximum number of blob or large-text attributes per object.
A feature currently being worked on is the ability to store and retrieve specific byte-ranges against BLOBs. This feature will enable you to work with binary data in a more natural and efficient manner than the typical "all-or-nothing" of most databases. This feature will allow you to get and set bytes the way your filesystem allows you to, at a low level.
Selectively index individual data attributes. Selectively query full-text attributes in full combination with your standard SQL queries. (e.g. SELECT $s:firstname, $s:lastname WHERE $s:state='NY' AND $workHistory.word()='lisp' AND $workHistory.word()='sql')
Additional MVCC-like options are planned for the other 'modify' sub-commands.
SchemafreeSQL delivers fast index-like queries without index configuration AND at the same time delivers inserts at fast no-index speeds.
As applications grow, the diversity of queries grow. To maintain acceptable query performance, it is common practice to create new indexes on both single columns and combinations of columns. However, when trying to create a composite index for every possible combination of queried column sets, you run into a serious problem…
For example, suppose you had just 10 columns on a table but user demands kept growing as to what columns they wanted to filter against. Even if the users only filtered against 3 of the 10 columns, there are 720 possible combinations of 3 column sets (10!/(10-3)!). Of course, you won't get close to making that many indexes anyway, as SQL databases have a hard (and practical) limit on how many you can create and/or how large your indexes can be. MyISAM for instance, has a limit of 64 indexes per table, and InnoDB has restrictions on the number of bytes per index (3072 bytes or about 768 chars). But regardless of the database limits, if you actually had 720 indexes on a table, INSERT speed would most likely grind to a halt. And this is only a simplistic scenario. If your table had 50 columns, there would be over 5 million four column combinations!
Fortunately, SchemafreeSQL removes this problem from your plate. With SchemafreeSQL, you get indexing for free. Not even a second of your time will be wasted on index design or optimization. And in case you are worrying - no, we are NOT creating composite indexes on demand in reaction to your queries. SchemafreeSQL provides you with the benefits of vast numbers of (hypotheical) composite indexes without the downfalls.
Date math is both a convenience feature and application enhancement/power feature. It allows an application or an application's
end-users to greatly simplify and extend the way date values are input.
It is available for use within the 'modify' command against 'date' and 'time' type attributes.
For Example: "+1M +5d" would calculate as 1 month and 5 days from now.
"1/1/2020 -5m" would calculate as 5 minutes before midnight Dec 31st 2019.
Year, Month, Week, Day, Hour, Minute and Second math is available for use.