Backendless Support
 
Answered

Why SQL?

I'm a new developer trying to do research on which platform i want to use for my mBaas Database. What i really want to know is:

why did you choose to build backendless on top of an SQL database when many others seem to choose NoSQL nowadays?

if you were creating an app that lets you build your profile and read blog posts from business users, would it be better to use NoSQL instead of SQL?

Isn't NoSQL easier to manage / scale, have better performance, and allow you to store more information?

isn't having to define a Schema a bad thing compared to a Schemaless option?

Best Answer
photo

Hi Alan,

We use a combination of SQL and NoSQL databases. The actual persistence storage in the mBaaS sense is an internal implementation detail where the backend should be viewed as a black box.

Our architecture is built in a way where the backend can scale infinitely in a complete transparency for the client side.

For your example of an app to read blog posts, Backendless can fit just fine as it offers multiple options for storing data. The metadata for the blog posts could be stored in the Data Service, while the actual articles may go into the File Service as file blobs. Alternatively, everything could be stored in the Data Service as I do not see any limitations that would impede on your ability to implement it.

As for the schema definition, it is completely optional as the first step. You can completely bypass Schema definition in console and drive the backend through the structure of the objects being persisted. Backendless creates/modifies schema on the fly as objects enter the backend.

Hope this helps.

Regards,

Mark

Leave a Comment

Comments (1)

photo
1

Hi Alan,

We use a combination of SQL and NoSQL databases. The actual persistence storage in the mBaaS sense is an internal implementation detail where the backend should be viewed as a black box.

Our architecture is built in a way where the backend can scale infinitely in a complete transparency for the client side.

For your example of an app to read blog posts, Backendless can fit just fine as it offers multiple options for storing data. The metadata for the blog posts could be stored in the Data Service, while the actual articles may go into the File Service as file blobs. Alternatively, everything could be stored in the Data Service as I do not see any limitations that would impede on your ability to implement it.

As for the schema definition, it is completely optional as the first step. You can completely bypass Schema definition in console and drive the backend through the structure of the objects being persisted. Backendless creates/modifies schema on the fly as objects enter the backend.

Hope this helps.

Regards,

Mark