Database design – Expectations

What we expect from a database, usually, is an ability to store and retrieve data. Also often abilities to quickly analyze data and possibly mutate/process data in an optimal and somewhat non-trivial way.

Given these expectations there are many database that are available today:
– some designed for structured data like RDBMS
– some designed for specific dimensions like time series databases, geo-spatial databases
– some designed on a specific class of datastructures like Hash table, for example, key-value stores or graphs, for example, neo4j
– some designed for unstructured data like blob storage services like GCS, S3, Azure blob

There are a few databases that offer multiple paradigms, for example, Postgres that offers both relational and GeoSpatial abilities.

What if we can imagine a database that allows
– Registering a datastructure (along with its permissible operations)
– Define a consistent query language across them, for example, using GraphQL – attempted this across different databases.
– Allow algorithms to be registered ontop of these datastructures ex: BreadFirstSearch ontop a graph datastructure
– Allow distributed variants of above algorithms to be registered.

and then allow the client to choose, optimize, change (when needed) how they want to store, process data.

This would be one way to standardize database system interfaces and also one consistent way to debate their characteristics and also may allow significantly simplifying DB migrations.

This post was later published on LinkedIn here.

Proudly powered by WordPress | Theme: Outfit Blog by Crimson Themes.