Why did we start SecureDB?

My co-founder Nikhil and I come from software development backgrounds. Between us, we have about 30 years of dev experience, in areas such as database internals development, storage technologies, web development, mobile development, Identity and Access Management.

In almost every project that we’ve worked on over the years, we had to shove encryption into the product and the marriage was not seamless. It was clunky, one-offish, and hard to maintain. When we looked at the state of data encryption, and looked at tools available to developers in this area, we knew instantly that this is an area that begs disruption. So, we decided to do something about it. And SecureDB was born.

We started thinking deeply about what should the characteristics of SecureDB be? We finally ended up with these three:

1. Encryption must be made simple

Our goal right from the beginning was that developers should be able to add encryption to their project in 10 minutes flat. Anything more, you create barriers for entry.

2. Encryption must be made default

Encryption should be the default and natural process that data goes through before being persisted in the databases. Encryption should be ‘naturally’ baked into the use case developers are implementing.

3. Encryption must be part of dev lifecycle

Developers need to have a say in how encryption is used. So, how do we build a product that gives developers full control? How do we build a product that makes developers life easy? And how do we help developers ‘sell’ encryption to their management?

To achieve this, we had to make SecureDB inexpensive to implement and quick to integrate with.

Here is a demo of SecureDB that shows how we’ve married the above three principles, right into the heart of the product. Feedback is welcome as always.

SecureDB Encryption as a Service Demo Video