Picking the database that works for all your stakeholders [Q&A]
Databases are employed by all kinds of businesses, but deciding which one to use can be a tricky decision. Once you've chosen a solution it’s a lot of work to switch to a different one.
But also different stakeholders within the enterprise have different requirements from a database and different views on which features are important.
So, how can you make sure you select a database solution that keeps everybody happy? We spoke to Suda Srinivasan, VP of strategy and solutions at SQL database platform Yugabyte to find out.
BN: Why are database decisions so critical to the success or failure of digital transformation or cloud migration and what are the guiding principles for picking a solution that works for everyone?
SS: There has been a universal pain point present throughout the entire age of the internet -- a mismatch between the applications and services that companies offer and the databases that power them. Over the past decade, enterprises have modernized their applications and embraced the cloud and modern DevOps practices in order to deliver always available, responsive applications to their users. This type of business transformation puts pressure on traditional systems of record, because traditional transactional databases that modern applications continue to use were not designed with the cloud in mind. This really creates the need for a different type of database -- one built for the cloud native world and capable of handling transactional workloads. However, picking the right database is tricky because the different stakeholders within an organization prioritize different capabilities when making database choices.
BN: Who are the key stakeholders when it comes to database decisions?
SS: Typically, there are three groups that will be quite invested in your database decisions -- application developers, operations teams, and technology leaders or architects. Additionally security teams care about how data is secured and how compliance is maintained. They all have different priorities and disparate lists of capabilities, all of which the database solution must satisfy to really work for the organizations.
BN: Can you gives us some examples of what this means for specific teams?
SS: Well, let's start with application developers. Developers typically want a database that minimizes disruption and frees them up to focus on building applications. A query interface that offers familiar SQL syntax and is compatible with well-known databases like PostgreSQL or MySQL allows them to reuse existing tools and code to save time. Also having resilience and scalability built into the database frees them from having to implement distributed transactions and consistency themselves. Databases that work well with modern cloud native frameworks and DevOps tools are ideal. Developers also prefer open source databases that allow them to leverage the rich ecosystem for learning and support.
Most operations and platform teams in agile organizations aim to deliver a private database-as-a-service to their developers, allowing devs to quickly provision databases for different environments. Ops teams prioritize the flexibility to deploy database clusters in any private, public, or hybrid cloud environment, on bare-metal, VMs, or containers. Databases that have built-in resilience and high availability and offer effortless horizontal scaling simplify day two operations for ops team, enabling maintenance operations like backups, upgrades, and security patching without downtime. The databases also may need to be deployed in geo-distributed topologies to enable low latency reads and writes, improve resilience, and maintain compliance with data sovereignty laws. And finally, data security is a foundational requirement for mission-critical databases that store sensitive data.
BN: So what about technology leaders and architects?
SS: Technology leaders and architects are a bit different due to their habit of thinking more about the medium to long term implications of their choice of database. They prefer database solutions that eliminate lock-in with any particular cloud provider or infrastructure platform. They want to lower the total cost of ownership for dev, staging, and production deployments by reducing licensing fees, lowering operational costs, and eliminating silos through consolidation. They also want to reduce the risk of moving apps and data to the cloud by controlling the pace of migration. This often means running the apps and data in an on-prem environment with the same container orchestration technology and database solution as in the cloud. Security is again a top concern.
At the end of the day any database solution must meet all of the above criteria or it'll get buy-in from one team but pushback from another.