Posted on

How to Set Up a GraphQL Endpoint on a Database

Introduction

I have been working around databases for about four decades (that does date me!). From the early days of System R and Ingres, through the commercial engines of DB2 and Oracle, the open sources of MySQL and Postgres, to the current generations of NoSQLs like MongoDB and Cassandra and scalable SQL like CockroachDB and Yugabyte, anyone who has predicted the demise of databases has proven to be wrong. SQL as the query language has persisted, evolved, and improved, but the basic select * from foo where x = 1 group by y  is the language known to hundreds of thousands of developers. Why is that? Because databases just work, and how can you say that about too many things?

As a frontend developer, you want to see data in logical business constructs. Say a customer has one or more addresses, then your React application would love to see data like this:

Posted on

Optimized File Formats – Reduce Overall System Latency

Since Optimized columnar file formats helped Big data ecosystem to have SQL query features, Organizations are now able to retrain their existing data warehouse or Database developers quickly in Big data technology and migrate their analytics applications to on-premise Hadoop clusters or cheap object storage in the cloud.

When Columnar file formats were first proposed in the early 2010s, the intention was to enable faster query execution engines on top of the Hadoop file system. The columnar format was explicitly designed to give much-improved query performance than conventional row-based file formats. Columnar file formats give much better performance than row-based file formats (used in conventional Databases and data warehouses) when a partial set of columns from a table are queried.