In the fundamental design, no schema does not design the application data store based on the relationship between data entities (like fixed schema). Rather, the design of the data store is flexible and dynamic based on the end user query/request against the enterprise application.

Let us illustrate this with a real-time example to understand it in a better way. In a traditional application, say the customer has been advised to share their data feed in a prescribed format, such as comma-separated, excel-based file, and the like. Here, the end customer is forced to send the input data layout strictly in the predefined format, required by the built enterprise application. On deviation from this fixed schema of input file, the system will reject the source abruptly.

In modern applications, this is completely reversed. For example, the Facebook application allows the end user to post/host their messages in whatever format they want. FB never instructs the end user to feed their input data using a predefined format. The FB users can post their input data in audio, video, message, images, of literally any format. Even within the image upload, FB allows the user to host the snapshot of any image format like JPG, BMP, GIF, PNG, and so on. For the end user of FB, this concept of no schema for input feed provides great flexibility.

We hope that these real-life examples of the traditional fixed schema and modern no-schema models clarify the key differences between them.

To illustrate more precisely, a matrix has been drafted with the x-axis representing Fixed Schema and No Schema along with y-axis as Flat Layout and Complex Layout. Four commonly used input feed sources like CSV, Avro, HBase, and JSON are categorized in the appropriate quadrants of the matrix, as shown in the following diagram:

The main strength of no-schema databases becomes known when using them in an object-oriented context with inheritance.

The key advantage of a schema-free database is that we can store the data as it is. By doing schema-free design, it will be challenging to impose the database structure rules. A good example is that of the flexibility to post any type of content (like audio, video, image, and others) on the Facebook wall.

Another advantage of a no-schema database is that it gives additional agility during development. It easily allows you to try new features without having to restructure your database during the later phases of the software development life cycle in the enterprise environment.

On the flipside of no schema usage, metadata is a vital component to interpret the meaning of the actual data store.