Unsexy Database Features That Matter: Part 2

Clock Icon

2 min read

Pencil Icon

Nov 12, 2013

Unsexy Database Features That Matter: Part 2

In the previous post, we talked about how you should focus on how people derive value from your product. Today we will focus on database management — your goal should always be 24/7 100% uptime.

how-people-manage-a-database-productHow People Manage A Database Product

deployment-time-to-get-the-system-up-and-runningDeployment (time to get the system up and running)

How much time does it take to get your product up and running? People have talked about barriers to entry for a long long time. The worst one is, “I couldn’t install your product so I gave up.” This is simply unforgivable.

Modern platforms offer wonderful turn-key deployment tools: rpm/deb for linux, virtual machine images and AMIs, Amazon Marketplace, cloud formation, docker containers. Pick your poison and do it right.

securitySecurity

Enterprise demands high security products. Kerberos authentication, password management policies. It’s unsexy, it boring, but it matters. Without it you can’t get into some of the most important enterprise accounts.

online-operationsOnline Operations

You would think that every database has a backup story, until you add one word to it: online. Online means that the backup doesn’t takes read or write locks for the duration of the backup and that the database state is consistent with regard to a specific point in time. Of course commercial databases have had this feature for a long time and some of the open source counterparts (Postgres) have it as well, but even MySQL and MongoDB don’t have a turn-key solution for this.

It’s relatively easy to have offline alter table that blocks all the reads and writes to the database. Online alter table is very hard to build, but it allows production systems to have zero downtime in the face of schema changes. We bit the bullet and built it. Needless to say, it’s a tremendous customer delight.

high-availabilityHigh Availability

Commodity hardware tends to fail. Non-commodity hardware tends to fail just as much. Your system must survive that with minimum downtime. As usual, it’s easier said than done, but you must have it, otherwise no one would want to run it in production.

conclusionConclusion

When you build a database server, it’s easy to get carried away with sexy things like exotic data structures, trendy new distributed designs, new query languages, etc. But you have to always invest in fundamentals just as much as you are investing in what makes your product unique and special to your customers.


Share