ruby javascript inspirational browser software architecture programming languages iot performance

The rise and fall of the Full Stack Database

Frank Lyaruu ยท Full Stack Fest 2017

There was a time not long ago when we used relational databases for everything. Even if the data wasn't particularly relational, we shoehorned it into relational tables, often because that was the only database we had. Now many NoSQL databases exits: Document, realtime, graph, column, but that does not solve the problem that the same data is a graph from one perspective, but a collection of documents from another. Can we build a data infrastructure where we can plug in any type of database as a 'view'? Can we add and remove different types of databases as our business case evolves? In other words, can we be agile in our choice of database? I think we can.

For our client Sportlink we've built a replication system based on Kafka and Kafka Streams, that replicates data from a relational database to several other databases. Need a real time front-end database? No problem, we can replicate to Firebase Realtime. Need full text search? Just pick what we should replicate to Elasticsearch.

Using the right tool for the job always pays out in the end.