Podcasts about dbaas

On this episode, we are joined by Ross Morrow, a Software Engineer at Finix, the payment processor working to create the most accessible financial services ecosystem in history. Finix's B2B payments platform is designed for flexibility and scalability, streamlining financial transactions for businesses and delivering a truly customer-centric experience. Faced with the need for a powerful database for real-time insights, Finix turned to Apache Druid. Listen to learn how they're able to access real-time data with sub-second query times, how they transformed their data operations, and how Imply Polaris is helping them get all the benefits of Druid without the burden of maintenance or overhead costs. If you'd like to learn more about Finix, please visit https://go.finix.com/ To learn more about Apache Druid or to download the latest version, please visit https://druid.apache.org/ Or to see what we're up to at Imply, please visit imply.io

Com Matheus Faria, Teach Lead e dev responsável pela criação do CEL Playground na Getup, gravamos nesse episódio um resumo das coisas mais interessantes que vimos no primeiro dia da Kubecon!Como participante do Contributor Summit, soubemos que o Kubernetes precisa de contribuidores para o etcd do código e que o pessoal está com dificuldades para manter a versão LTS do Kubernetes. A outra foi ver que podemos tratar Banco de Dados como serviço (DBaaS).LINKS do programa:CEL Playground - https://undistro.io/cel/ CEL Playground with WebAssembly- https://undistro.io/blog/challenges-in-developing-cel-playground/O Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão em getup.io/kubicast, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.

VMware Data Services Manager is a software solution that provides the same convenience as a public cloud-based DBaaS platform, but it is installed and managed on-premises eliminating the challenges of building a custom on-premises DBaaS platform. It helps enterprise IT team stays in control, automate day 2 operations to free up valuable DBA time and provide App developers with the agility they need. On this episode of the Virtually Speaking Podcast. Michael Gandy and Christos Karamanolis share the details on how VMware is helping customers to implement a DBaaS on vSphere and how it fits into the “Cloud Smart” strategy. Watch the video of this episode Watch all VMware Explore Recap episodes

Summary Data persistence is one of the most challenging aspects of computer systems. In the era of the cloud most developers rely on hosted services to manage their databases, but what if you are a cloud service? In this episode Vignesh Ravichandran explains how his team at Cloudflare provides PostgreSQL as a service to their developers for low latency and high uptime services at global scale. This is an interesting and insightful look at pragmatic engineering for reliability and scale. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management Introducing RudderStack Profiles. RudderStack Profiles takes the SaaS guesswork and SQL grunt work out of building complete customer profiles so you can quickly ship actionable, enriched data to every downstream team. You specify the customer traits, then Profiles runs the joins and computations for you to create complete customer profiles. Get all of the details and try the new product today at dataengineeringpodcast.com/rudderstack (https://www.dataengineeringpodcast.com/rudderstack) This episode is brought to you by Datafold – a testing automation platform for data engineers that finds data quality issues before the code and data are deployed to production. Datafold leverages data-diffing to compare production and development environments and column-level lineage to show you the exact impact of every code change on data, metrics, and BI tools, keeping your team productive and stakeholders happy. Datafold integrates with dbt, the modern data stack, and seamlessly plugs in your data CI for team-wide and automated testing. If you are migrating to a modern data stack, Datafold can also help you automate data and code validation to speed up the migration. Learn more about Datafold by visiting dataengineeringpodcast.com/datafold (https://www.dataengineeringpodcast.com/datafold) You shouldn't have to throw away the database to build with fast-changing data. You should be able to keep the familiarity of SQL and the proven architecture of cloud warehouses, but swap the decades-old batch computation model for an efficient incremental engine to get complex queries that are always up-to-date. With Materialize, you can! It's the only true SQL streaming database built from the ground up to meet the needs of modern data products. Whether it's real-time dashboarding and analytics, personalization and segmentation or automation and alerting, Materialize gives you the ability to work with fresh, correct, and scalable results — all in a familiar SQL interface. Go to dataengineeringpodcast.com/materialize (https://www.dataengineeringpodcast.com/materialize) today to get 2 weeks free! Your host is Tobias Macey and today I'm interviewing Vignesh Ravichandran about building an internal database as a service platform at Cloudflare Interview Introduction How did you get involved in the area of data management? Can you start by describing the different database workloads that you have at Cloudflare? What are the different methods that you have used for managing database instances? What are the requirements and constraints that you had to account for in designing your current system? Why Postgres? optimizations for Postgres simplification from not supporting multiple engines limitations in postgres that make multi-tenancy challenging scale of operation (data volume, request rate What are the most interesting, innovative, or unexpected ways that you have seen your DBaaS used? What are the most interesting, unexpected, or challenging lessons that you have learned while working on your internal database platform? When is an internal database as a service the wrong choice? What do you have planned for the future of Postgres hosting at Cloudflare? Contact Info LinkedIn (https://www.linkedin.com/in/vigneshravichandran28/) Website (https://viggy28.dev/) Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ (https://www.pythonpodcast.com) covers the Python language, its community, and the innovative ways it is being used. The Machine Learning Podcast (https://www.themachinelearningpodcast.com) helps you go from idea to production with machine learning. Visit the site (https://www.dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com (mailto:hosts@dataengineeringpodcast.com)) with your story. To help other people find the show please leave a review on Apple Podcasts (https://podcasts.apple.com/us/podcast/data-engineering-podcast/id1193040557) and tell your friends and co-workers Links Cloudflare (https://www.cloudflare.com/) PostgreSQL (https://www.postgresql.org/) Podcast Episode (https://www.dataengineeringpodcast.com/postgresql-with-jonathan-katz-episode-42/) IP Address Data Type in Postgres (https://www.postgresql.org/docs/current/datatype-net-types.html) CockroachDB (https://www.cockroachlabs.com/) Podcast Episode (https://www.dataengineeringpodcast.com/cockroachdb-with-peter-mattis-episode-35/) Citus (https://www.citusdata.com/) Podcast Episode (https://www.dataengineeringpodcast.com/citus-data-with-ozgun-erdogan-and-craig-kerstiens-episode-13/) Yugabyte (https://www.yugabyte.com/) Podcast Episode (https://www.dataengineeringpodcast.com/yugabytedb-planet-scale-sql-episode-115/) Stolon (https://github.com/sorintlab/stolon) pg_rewind (https://www.postgresql.org/docs/current/app-pgrewind.html) PGBouncer (https://www.pgbouncer.org/) HAProxy Presentation (https://www.youtube.com/watch?v=HIOo4j-Tiq4) Etcd (https://etcd.io/) Patroni (https://patroni.readthedocs.io/en/latest/) pg_upgrade (https://www.postgresql.org/docs/current/pgupgrade.html) Edge Computing (https://en.wikipedia.org/wiki/Edge_computing) The intro and outro music is from The Hug (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/Love_death_and_a_drunken_monkey/04_-_The_Hug) by The Freak Fandango Orchestra (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/) / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/)

Parikshit Savjani joins Scott Hanselman to discuss the evolution of Azure Database for MySQL, an open-source MySQL database on Azure. The conversation focuses on the journey from the Single Server deployment model to the new and improved Flexible Server offering, which represents a fully managed MySQL database-as-a-service (PaaS or DBaaS) running on Azure. Learn all about Azure Database for MySQL - Flexible Server, including its top features related to performance, security, and high-availability, its simplified migration experience, and how easy and cost-effective it is to get started. Chapters 00:00 - Introduction 02:16 - Demo: Azure Database for MySQL in the Azure portal 06:02 - Demo: Failover experience 09:08 - Planned failover 10:16 - Backup and restore 11:00 - Migrating to flexible server 13:56 - Wrap-up Recommended resources Azure Database for MySQL Azure Database for MySQL documentation Create your first Azure Database for MySQL flexible server Azure Database for MySQL Resources Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Parikshit Savjani | Twitter: @talktosavjani Azure Database for MySQL | Twitter: @AzureDBMySQL Azure Friday | Twitter: @AzureFriday Azure | Twitter: @Azure Azure Database for MySQL | YouTube: @AzureDBMySQL

Parikshit Savjani joins Scott Hanselman to discuss the evolution of Azure Database for MySQL, an open-source MySQL database on Azure. The conversation focuses on the journey from the Single Server deployment model to the new and improved Flexible Server offering, which represents a fully managed MySQL database-as-a-service (PaaS or DBaaS) running on Azure. Learn all about Azure Database for MySQL - Flexible Server, including its top features related to performance, security, and high-availability, its simplified migration experience, and how easy and cost-effective it is to get started. Chapters 00:00 - Introduction 02:16 - Demo: Azure Database for MySQL in the Azure portal 06:02 - Demo: Failover experience 09:08 - Planned failover 10:16 - Backup and restore 11:00 - Migrating to flexible server 13:56 - Wrap-up Recommended resources Azure Database for MySQL Azure Database for MySQL documentation Create your first Azure Database for MySQL flexible server Azure Database for MySQL Resources Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Parikshit Savjani | Twitter: @talktosavjani Azure Database for MySQL | Twitter: @AzureDBMySQL Azure Friday | Twitter: @AzureFriday Azure | Twitter: @Azure Azure Database for MySQL | YouTube: @AzureDBMySQL

hat deliver "Wow!" moments to customers. Vinay also delves into data sovereignty and how organizations often center their discussions around data residency for compliance purposes. He explains that true data sovereignty is an extension of sovereignty over an organization's stack and that heavy users of public clouds and their services, such as DBaaS, are not truly sovereign. However, it's not a binary proposition, and there are varying degrees of sovereignty. Vinay also touches on the importance of stack decisions being made based on balancing capabilities and risk tolerance, not convenience. He also points out the risks of cloud deployment models, including vendor, environment, ecosystem lock-in, database license type and stability, key-man risk, cost predictability, etc. Vinay shares that the landscape has evolved to enable organizations to get the convenience of cloud deployment models and the reliability and scalability of DBaaS without sacrificing their sovereignty wholesale. Please tune in to learn more about data sovereignty and how organizations can make informed decisions about their data stack.

Welcome to Day Two Cloud! On today's episode---databases. More specifically, controlling your databases. We're discussing the database control plane company Severalnines with CEO Vinay Joosery. Severalnines is sponsoring today's discussion about sovereign Databases as a Service (DBaaS). The post Day Two Cloud 170: Sovereign DBaaS And Severalnines (Sponsored) appeared first on Packet Pushers.

Welcome to Day Two Cloud! On today's episode---databases. More specifically, controlling your databases. We're discussing the database control plane company Severalnines with CEO Vinay Joosery. Severalnines is sponsoring today's discussion about sovereign Databases as a Service (DBaaS). The post Day Two Cloud 170: Sovereign DBaaS And Severalnines (Sponsored) appeared first on Packet Pushers.

Welcome to Day Two Cloud! On today's episode---databases. More specifically, controlling your databases. We're discussing the database control plane company Severalnines with CEO Vinay Joosery. Severalnines is sponsoring today's discussion about sovereign Databases as a Service (DBaaS). The post Day Two Cloud 170: Sovereign DBaaS And Severalnines (Sponsored) appeared first on Packet Pushers.

Cloud N Clear episode 132 is AVAILABLE NOW!

https://go.dok.community/slack https://dok.community ABSTRACT OF THE TALK Percona is committed to deliver solutions to run open source databases anywhere without lock in. As part of this commitment, we have created Operators to run MySQL, PostgreSQL and MongoDB on Kubernetes. Learn how Percona Monitoring and Management (PMM) allows you to enable developers to deploy and manage databases anywhere with private Database-as-a-service capability backed by Operators. BIO Product and technology leader. Worked in various fields: internet service providers, financial sector and merge & acquisition business. Currently leads product @ Percona focusing on cloud native technologies for open source databases KEY TAKE-AWAYS FROM THE TALK Learn how Percona Monitoring and Management (PMM) allows you to enable developers to deploy and manage databases anywhere with private Database-as-a-service capability backed by Operators. You will get high level overview of Percona's Operators structure and how private DBaaS can boost the productivity of your engineering and IT teams.

В этом выпуске: чему мы научились за неделю; Используем Property-Based тесты в Rust; Храним онтологии в самых передовых DBaaS; Храним телеметрию; Храним твиты и фоточки в Perkeep; Храним… [00:02:19] Чему мы научились за неделю https://www.universetoday.com/105496/technicolor-auroras-a-reality-check/ https://twitter.com/sum3rman/status/1508381700467965961 2022-03 Lapland | Flickr Sound — Precision editing by frequency in Audacity using the spectrograph display — YouTube Spectral… Читать далее →

These days, every company looking at analyzing their data for insights has a data pipeline setup. Many companies have a fast production database, often a NoSQL or key-value store, that goes through a data pipeline.The pipeline process performs some sort of extract-transform-load process on it, then routes it to a larger data store that the analytics tools can access. But what if you could skip some steps and speed up the process with a database purpose-built for analytics?On this sponsored episode of the podcast, we chat with Rohit (Ro) Amarnath, the CTO at Vertica, to find out how your analytics engine can speed up your workflow. After a humble beginning with a ZX Spectrum 128, he's now in charge of Vertica Accelerator, a SaaS version of the Vertica database. Vertica was founded by database researcher Dr. Michael Stonebreaker and Andrew Palmer. Dr. Stonebreaker helped develop several databases, including Postgres, Streambase, and VoltDB. Vertica was born out of research into purpose-built databases. Stonebreaker's research found that columnar database storage was faster for data warehouses because there were fewer read/writes per request. Here's a quick example that shows how columnar databases work. Suppose that you want all the records from a specific US state or territory. There are 52 possible values here (depending on how you count territories). To find all instances of a single state in a row-based DB, the search must check every row for the value of the state column. However, searching by column is faster by an order of magnitude: it just runs down the column to find matching values, then retrieves row data for the matches. The Vertica database was designed specifically for analytics as opposed to transactional databases. Ro spent some time at a Wall Street firm building reports—P&L, performance, profitability, etc. Transactions were important to day-to-day operations, but the real value of data came from analyses that showed where to cut costs or increase investments in a particular business. Analytics help with overall strategy, which tends to be more far-reaching and effective. For most of its life, Vertica has been an on-premises database managing a data warehouse. But with the ease of cloud storage, Vertica Accelerator is looking to give you a data lake as a service. If you're unfamiliar, data lakes take the data warehouse concept—central storage for all your data—and remove limits. You can have “rivers” of data flowing into your stores; if you go from a terabyte to a petabyte overnight, your cloud provider will handle it for you. Vertica has worked with plenty of industries that push massive amounts of data: healthcare, aviation, online games. They've built a lot of functionality into the database itself to speed up all manner of applications. One of their prospective customers had a machine learning model with thousands of lines of code that was reduced to about ten lines because so much was being done in the database itself. In the future, Vertica plans to offer more powerful management of data warehouses and lakes, including handling the metadata that comes with them. To learn more about Vertica's analytics databases, check out our conversation or visit their website.

These days, every company looking at analyzing their data for insights has a data pipeline setup. Many companies have a fast production database, often a NoSQL or key-value store, that goes through a data pipeline.The pipeline process performs some sort of extract-transform-load process on it, then routes it to a larger data store that the analytics tools can access. But what if you could skip some steps and speed up the process with a database purpose-built for analytics?On this sponsored episode of the podcast, we chat with Rohit (Ro) Amarnath, the CTO at Vertica, to find out how your analytics engine can speed up your workflow. After a humble beginning with a ZX Spectrum 128, he's now in charge of Vertica Accelerator, a SaaS version of the Vertica database. Vertica was founded by database researcher Dr. Michael Stonebreaker and Andrew Palmer. Dr. Stonebreaker helped develop several databases, including Postgres, Streambase, and VoltDB. Vertica was born out of research into purpose-built databases. Stonebreaker's research found that columnar database storage was faster for data warehouses because there were fewer read/writes per request. Here's a quick example that shows how columnar databases work. Suppose that you want all the records from a specific US state or territory. There are 52 possible values here (depending on how you count territories). To find all instances of a single state in a row-based DB, the search must check every row for the value of the state column. However, searching by column is faster by an order of magnitude: it just runs down the column to find matching values, then retrieves row data for the matches. The Vertica database was designed specifically for analytics as opposed to transactional databases. Ro spent some time at a Wall Street firm building reports—P&L, performance, profitability, etc. Transactions were important to day-to-day operations, but the real value of data came from analyses that showed where to cut costs or increase investments in a particular business. Analytics help with overall strategy, which tends to be more far-reaching and effective. For most of its life, Vertica has been an on-premises database managing a data warehouse. But with the ease of cloud storage, Vertica Accelerator is looking to give you a data lake as a service. If you're unfamiliar, data lakes take the data warehouse concept—central storage for all your data—and remove limits. You can have “rivers” of data flowing into your stores; if you go from a terabyte to a petabyte overnight, your cloud provider will handle it for you. Vertica has worked with plenty of industries that push massive amounts of data: healthcare, aviation, online games. They've built a lot of functionality into the database itself to speed up all manner of applications. One of their prospective customers had a machine learning model with thousands of lines of code that was reduced to about ten lines because so much was being done in the database itself. In the future, Vertica plans to offer more powerful management of data warehouses and lakes, including handling the metadata that comes with them. To learn more about Vertica's analytics databases, check out our conversation or visit their website.

#CloudNClear is here with host Narine Galstian, CMO, SADA, who will be interviewing another friend and #SaaS #Alliance #Partner, Franz Aman, CMO, MariaDB. Tune in on-demand as they unveil how the #partnership has allowed MariaDB to differentiate their go-to-market strategies for #SkySQL, and why they originally decided to enter the #database market on the #GoogleCloudPlatform. They discuss the #technical depth of #GCP and how our team provided #nextlevel, unmatched core competency around #Kubernetes. Find out how MariaDB is #partnering to provide a simple #datamanagement solution, and why other #partners like them are going all-in with SADA and @GoogleCloud. LISTEN, DOWNLOAD, & SUBSCRIBE!   Host: Narine Galstian | CMO, SADA Guests: Franz Aman | CMO, MariaDB   Connect on Twitter: https://twitter.com/cloudnclear https://twitter.com/SADA https://twitter.com/ngalstian https://twitter.com/franzaman   Connect on LinkedIn: https://www.linkedin.com/company/sada/ https://www.linkedin.com/in/ngalstian/ https://www.linkedin.com/in/franzaman/

Cognizant's emphasis on innovation by being on the forefront of technology, has enabled Cognizant to get stay ahead of the curve. Bi-modal IT promotes the idea of a digital core which is stable and robust by nature and an extension layer which enables agility and shorter innovation cycles. SAP Cloud Platform is the PaaS offering from SAP which implements the idea of bi-modal IT. Cognizant has been partnering with SAP-on-SAP Cloud Platform from inception. As early adopters of the SAP's PaaS offering, Cognizant has developed many innovative solutions helping customers improve their business processes with little or no modifications to the core. Services such as IoT, Machine Learning, Mobility, Portal, Integration, DBaaS and Analytics were the first few leading-edge technologies using which Cognizant has built solution offerings in the core manufacturing and supply chain space, for the Manufacturing, LifeSciences, and other industries. This journey has put Cognizant in a very competitive position to help our customers adopt SCP which is now SAP Business Technologies Platform. Our strong capabilities and extensive experience in Data, Analytics, App development, Integration and emerging technologies has enabled us to be a trusted partner to our customers in choosing the right platform. Some of our engagements with customers in their technology journey to make a right choice and implement it first time right. This includes customers in Life sciences, Manufacturing, Automobile, and Education. Chandra Natarajan AVP – Head Analytics and Platforms CoE, SAP Practice, Cognizant. Sandeep Sosale Sr. Director – Lead Platform Tech Solutions, SAP Practice, Cognizant. Christine Evans (Moderator) Director, Global Ecosystem and Midmarket Marketing

About EdEd Boyajian, President and CEO of EDB, drives the development and execution of EDB's strategic vision and growth strategy in the database industry, steering the company through 47 consecutive quarters of recurring revenue growth. He also led EDB's acquisition of 2ndQuadrant, a deal that brought together the world's top PostgreSQL experts and positioned EDB as the largest dedicated provider of PostgreSQL products and solutions worldwide. A 15+ year veteran of the open source software movement, Ed is a seasoned enterprise software executive who emphasizes that EDB must be a technology-first business in order to lead the open source data management ecosystem. Ed joined EDB in 2008 after serving at Red Hat, where he rose to Vice President and General Manager of North America. While there, he played a central leadership role in the development of the modern business model for bringing open source to enterprises.Links:EDB: https://enterprisedb.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring. Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is a treasure and a delight. Longtime listeners of this show know that it's not really a database—unless of course, it's Route 53—and of course, I don't solve pronunciation problems with answers that make absolutely everyone hate me. Longtime listeners of the show know that if there's one thing I adore when it comes to databases—you know, other than Route 53—it is solving pronunciation holy wars in such a way that absolutely everyone is furious with me as a result, and today is no exception. My guest is Ed Boyajian, the CEO of EDB, a company that effectively is the driving force behind the Postgres-squeal database. Ed, thank you for joining me.Ed: Hey, Corey.Corey: So, I know that other people pronounce it ‘post-gree,' ‘Postgresql,' ‘Postgres-Q-L,' all kinds of other things. We know it's decidedly not ‘Postgres-squeal,' which is how I go for it. How do you pronounce it?Ed: We say ‘Postgres,' and this is one of the great branding challenges this fantastic open-source project has endured over many years.Corey: So, I want to start at the very beginning because when I say that you folks are the driving force behind Postgres—or Postgres-squeal—I mean it. I've encountered folks from EDB—formerly EnterpriseDB—in the wild in consulting engagements before, and it's great because whenever we found an intractable database problem, back at my hands-on keyboard engineering implementation days, very quickly after you folks got involved, it stopped being a problem, which is kind of the entire point. A lot of companies will get up there and say, “Oh, it's an open-source project,” with an asterisk next to it and 15 other things that follow from it, or, “Now, we're changing our license so the big companies can't compete with us.” Your company's not named after Postgres-squeal and you're also—when you say you have people working on it, we're not talking just one or two folks; your fingerprints are all over the codebase. How do you engage with an open-source project in that sense?Ed: First and foremost, Postgres itself is, as you know, an independent open-source project, a lot like Linux. And that means it's not controlled by a company. I think that's inherently one of Postgres's greatest strengths and assets. With that in mind, it means that a company like EDB—and this started when I came to the company; I came from Red Hat, so I've been in open-source for 20 years—when I came to the company back in 2008, it starts with a commitment and investment in bringing technology leaders in and around Postgres into a business like EDB, to help enterprises and customers. And that dynamic intersection between building the core database in the community and addressing customer needs in a business, at that intersection is where the magic happens. And we've been doing that since I joined EDB in 2008; it was really an explicit focus for the company.Corey: I'd like to explore a little bit, well first and foremost, this story of is there a future for running databases in cloud environments yourself? And I have my own angry, loud opinion on this that I'm sure we'll get to momentarily, but I want to start with yours. Who is writing their own databases in the Year of our Lord 2021, rather than just using whatever managed thing is their cloud provider of choice today is offering for them?Ed: Well, let me give you context, Corey, because I think it matters. We've been bringing enterprise Postgres solutions to companies now, since the inception of the company, which dates back to 2004, and over that trajectory, we've been helping companies as they've done really two things: migrate away, in particular from Oracle, and land on Postgres, and then write new apps. Probably the first ten of the last 13 years since I've been in the company, the focus was in traditional on-prem database transformations that companies were going through. In the last three years, we've really seen an acceleration of that intersection of their traditional deployments and their cloud deployments. Our customers now, who are represented mostly in the Fortune 500 and Global 2000, 40% of our customers report they're deploying EDB's Postgres in the cloud, not in a managed context, but in a traditional EC2 or GCP self-managed cloud deployment.Corey: And that aligns with what I've seen, a fair bit. Years ago, I wound up getting the AWS Cloud Practitioner Certification—did a whole blog post on it—not because it was opening any doors for me, but because it let me get into the certified lounge at re:Invent, and ideally charge a battery and have some mostly crappy coffee. The one question I got wrong was I was honest when I answered, “How long does it take to restore an RDS database from snapshot backup?” Rather than giving the by-the-book answer, which is way shorter than I found in practice a fair bit of the time. And that's the problem I always ran into is that when you're starting out and building something that needs a database, and it needs a relational database that runs in that model so all the no SQL options are not viable for whatever reason, great, RDS is great for getting you started, but there's only so much that you can tune and tweak before you start to run into issues were, for particular workloads as they scale-out, it's no longer a fit for a variety of reasons.And most of the large companies that I work with that are heavily relational-database-driven have either started off or migrated to the idea of, “Oh, we're going to run our own databases on top of EC2 instances,” for a variety of reasons that, again, the cloud providers will say, “Oh, that's not accurate, and they're doing the wrong thing.” But, you know, it takes a certain courage to tell a large-scale customer, “You're doing it wrong.” “Well, why is that?” “Because I have things to sell you,” is kind of a terrible answer. How do you see it? Let's not pick on RDS, necessarily, because all of the cloud providers offered managed database offerings. Where do those make sense and where do they fall down?Ed: Yeah, I think many of our customers who made their first step into cloud picked a single vendor to do it, and we often hear AWS is been that early, early—Corey: Yeah, a five-year head start makes a pretty compelling story.Ed: That's right. And let's remember what these vendors are mostly. They are mostly infrastructure companies, they build massive data centers and set those up, and they do that beautifully well. And they lean on software, but they're not software companies themselves. And I think the early implementation of many of our customers in cloud relied on what I'll call relatively lightweight software offerings from their cloud vendor, including database.They traded convenience, ease of use, an easy on-ramp, and they traded some capability in some depth for that. And it was a good trade, in fact. And for a large number of workloads it may still be a good trade. But our more sophisticated customers, enterprise customers who are running Postgres or databases at scale in their traditional environments have long depended on a very intimate relationship with their database technology vendor. And that relationship is the intersection of their evolving and emerging needs and the actual development of the database capabilities in support of that.And that's the heart of who we are at EDB and what we do with Postgres and the many people we have committed to doing that. And we don't see our customers changing that appetite. So, I think for those customers, they've emerged more aware of the need to have a primary relationship with a database vendor and still be in cloud. And so I think that's how this evolves to see two different kinds of services side-by-side, what they really want is a Database as a Service from the database vendor, which is what we just announced here at Microsoft Ignite event.Corey: So, talk to me a little bit more about that, where it's interesting in 2021 to see a company launching a managed service offering, especially in the database space, when there's been so much pushback in different ways against the large cloud providers—[cough] Amazon—who tend to effectively lose sleep at night over the haunting fear that someone who isn't them is making money, somehow. And they will take whatever is available to them and turn it into a managed service offering. That's always been the fear, so people play games with licenses and the rest. Well, they've been running Postgres offerings for a long time. It is an independent open-source project.I don't think you can wind up forcing a license change through that says everyone except big companies can run this themselves and don't do a managed service with it because that cat is very much out of the bag. How is it that you're taking something to market now and expecting that to fare competitively?Ed: So, I think there's a few things that our customers are clearly telling us they want, and I think this is the most important thing: they want control of their data. And if you step back, Corey, look at it historically, they made a huge trade to big proprietary database companies, companies like Oracle, and they made that trade actually for convenience. They traded data to that database vendor. And we all know the successes Oracle's had, and the sheer extraordinary expense of those technologies. So, it felt like a walled garden.And that's where EDB and Postgres entered to really change that equation. What's interesting is the re-platforming that happened and the transformation to cloud actually had the same, kind of, binding effect; we now moved all that data over to the public cloud vendors, arguably in an even stickier context, and now I think customers are realizing that's created a dimension of inflexibility. It's also created some—as you rightly pointed out—some deficiencies in technical depth, in database, and in software. So, our customers have sorted that out and are kind of coming back to middle. And what they're saying is, “Well, we want all the advantages of an open-source database like a Postgres, but we want control of the data.”And so what control looks like is more the ability to take one version of that software—in our case, we're worrying about Postgres—and deploy the same thing everywhere they go. And that opens the door up for EDB to be their partner as a traditional on-prem partner, in the cloud where they run our Postgres and they manage it themselves, and as their managed service, Postgres Database as a Service Provider, which is what we're doing.Corey: I've been something of a bear on the idea of, “I'm going to build a workload to run everywhere in every cloud provider,” which I get. I think that's generally foolish, and people chasing that, with remarkably few exceptions, are often going after the wrong thing. That said, I'm also a fan of having a path to strategic Exodus, where Google's Cloud Spanner is fascinating, DynamoDB is revelatory, Cosmos DB is a security nightmare, which is neither here nor there, but the idea that I can take a provider's offering that even if it solves a bunch of problems for me, well, if I ever need to move this somewhere else for any reason, I'm re-architecting, my data model and re-architecting the built-in assumptions around how the database acts and behaves, and that is a very heavy lift. We have proof of that from Amazon, who got up on stage and told a story about how much they hate Oracle, and they're migrating everything off of Oracle to Aurora, which they had to build in order to get off of Oracle, and it took them three years to migrate things. And Oracle loves telling that story, too.And it's, you realize you both sound terrible when you tell that story? It's, “This is a massive undertaking that even we struggle with, so you should probably not attempt it.” Well, what I hear from that is good God, don't wind up getting locked into a particular database that is only available from one source. So, if you're all-in on a cloud provider, which I'm a fan of, personally—I don't care which one but pick a cloud provider—having a database that is not only going to work in that environment is just a reasonable step as far as how I view things. Trading up that optionality has got to pay serious dividends, and in many database use cases, I've just don't see it.Ed: Yeah, I think you're bringing up a really important point. So, let's unpack it for a minute.Corey: Please.Ed: Because I think you brought up some really prominent specialty database technologies, and I'm not sure there's ever a way out of that intersection and commitment to a single vendor if you pick their specialty database. But underneath this is exactly one of the things that we've worried about here at EDB, which is to make Postgres a more capable, robust database in its entirety. A Postgres superpower is its ability to run a vast array of workloads. Guess what, it's not sexy. It's not sexy not to be that specialty database, but it's incredibly powerful in the hands of an enterprise who can do more.And that really creates an opportunity, so we're trying to make Postgres apply to a much broader set of workloads, from traditional systems of record, like your ERP systems; systems of analysis, where people are doing lightweight analytic workloads or reporting, you can think in the world of data warehouse; and then systems of engagement, where customers are interacting with a website and have a database on the backend. All areas Postgres has done incredibly well in and we have customer experience with. So, when you separate out that core capability and then you look at it on a broader scale like Postgres, you realize that customers who want to make Postgres strategic, by definition need to be able to deploy it wherever they want to deploy it, and not be gated or bound by one cloud vendor. And all the cloud vendors picked up Postgres offerings, and that's been great for Postgres and great for enterprises. But that corresponding lock-in is what people want to get away from, at this point.Corey: There's something to be said for acknowledging that there is a form of lock-in as far as technology selection goes. If you have a team of folks who are terrific at one database engine and suddenly you're switching over to an entirely different database, well, folks who spent their entire career working on one particular database that's still in widespread use are probably not super thrilled to stick around for that. Having something that can migrate from environment to environment is valuable and important. When you say you're launching this as a database as a service offering, how does that actually work? Is that going to be running in your own cloud environment somewhere and people just make queries across the wire through standard connections to the database like they would something locally? Are you running inside of their account or environment? Is it something else?Ed: So, this is a fully-managed database as a service, just like you'd get from any cloud vendor or DBAAS vendor that you've worked with in the past, just being managed and run by EDB. And with that, you get lot of the goodies that we bring, including our compatibility, and all our deep Postgres expertise, but I think one of the other important attributes is we're going to run that service in our clients' account, which gives them a level of isolation and a level of independence that we think is really important. And as different as that is, it's not heroic; it's exactly what our customers told us they wanted.Corey: There's something to be said for building the thing that your customers have said that they want and make sense for you to build as opposed to, “We're going to build this ridiculous thing and we're sure folks are going to love it.” It's nice to see that shaping up in the proper order. And I've fallen victim to that myself; I think most technologists have to some extent. How big is EDB these days?Ed: So, we have over 650 employees. Now, around the world, we have 6000 customers. And of the 650 employees, about 300 of those are focused on Postgres. A subset of that are 30-odd core team members in the Postgres community, committers in the Postgres community, major contributors, and contributors in the Postgres community. So, we have a density of technical depth that is really unparalleled in Postgres.Corey: You're not, for lack of a better term, pulling an Amazon, insofar as you're, “Well, we have three people working on open-source projects, so we're going to go ahead and claim we're an open-source company,” in other words. Conversely, you're also not going down the path of this is a project that you folks have launched, and it claims to be open-source because we love it when people volunteer for for-profit entities, but we exercise total control over the project. You have a lot of contributors, but you're also still a minority, I think the largest minority, but still a minority of people contributing to Postgres.Ed: That's right. And, look, we're all-in on Postgres, and it's been that way since I got here. As I mentioned earlier, I came from Red Hat where I was—I was at Red Hat for a little over six years, so I've been an open-source now for 20 years. So, my orientation is towards really powerful, independent open-source projects. And I think we'll see Postgres really be the most transformative open-source technology since Linux.I think we'll see that as we look forward. And you're right, though, I think what's powerful about Postgres is it's an independent project, which means it's supported by thousands of contributors who aren't tied to single companies, around the world. And it just makes the software—we develop innovation faster, and I think it makes the software better. Now, EDB plays a big part in there. Roughly, a little less than a third of the last res—actually, the 13 release—were contributions that came from contributors who came from EDB.So, that's not a majority, and that's healthy. But it's a big part of what helps move Postgres along and there aren't—you know, the next set of companies are much, much—next set of combined contributors add up to quite small numbers. But the cloud vendors are virtually non-existent in that contribution.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: Something else that does strike me as, I guess, strange, just because I've seen so many companies try to navigate this in different ways with varying levels of success. I always encountered EDB—even back when it was EnterpriseDB, which was, given their love of acronyms, I'm still somewhat partial to. I get it; branding, it's a thing—but the folks that I engaged with were always there in a consulting service's capacity, and they were great at this. Is EDB a services company or a product company?Ed: Yeah, we are unashamedly a product technology company. Our business is over 90% of our revenue is annually recurring subscription revenue that comes from technical products, database server, mostly, but then various adjacent capabilities in replication and other areas that we add around the database server itself. So no, we're a database technology company selling a subscription. Now, we help our customers, so we do have a really talented team of consultants who help our customers with their business strategy for Postgres, but also with migrations and all the things they need to do to get Postgres up and running.Corey: And the screaming, “Help, help, help, fix it, fix it, fix it now,” emergencies as well.Ed: I think we have the best Postgres support operation in the world. It is a global 24/7 organization, and I think a lot of what you likely experienced, Corey, came out of our support organization. So, our support guys, these guys aren't just handling lightweight issues. I mean, they wade into the gnarly questions and challenges that customers face. But that's a support business for us. So, that's part and parcel. You get that, it's included with the subscription.Corey: I would not be remembering this for 11 years later, if it hadn't been an absolutely stellar experience—or a horrible experience, for that matter; one or the other. You remember the superlatives, not the middle of the road ones—and if it hadn't been important. And it was. It also noteworthy; with many vendors that are product-focused, their services may have an asterisk next to it because it's either a, “Buy our product and then we'll support it,” or it's, “Ohh, we're going to sell you a whole thing just to get us on the phone.” And as I recall, there wasn't a single aspect of upsell involved in this.It was, “Let's get you back up and running and solve the problem.” Sure, later in time, there were other conversations, as all good businesses will have, but there was no point during those crisis moments where it felt like, “Oh, if you had gone ahead and bought this thing that we sell, this wouldn't happen,” or, “You need to buy this or we won't help you.” I guess that's why I've contextualized you folks as a services company, first and foremost.Ed: Well, I'm glad you have that [laugh] experience because that's our goal. And I think—look, this is an interesting point where customers want us to bring that capability to their managed DBAAS world. Step back again, go back to what I said about the big cloud vendors; they are, at their core, infrastructure companies. I mean, they're really good at that. They're not particularly well-positioned to take your Postgres call, and I don't think they want that call.We're the other guys; we want to help you run your Postgres, at scale, on-prem, in the cloud, fully managed in the cloud, by EDB, and solve those problems at the same time. And I think that's missing in the market today. And we can step back and look at this overall cloud evolution, and I think some might think, “Gee, we're into the mature phase of cloud adoption.” I would tell you, since the Red Sox have done well this year, I think in a nine-inning baseball game—for those of your listeners who follow American baseball—we're in, like, the top of the second inning, maybe. Maybe the bottom of the second inning. So, we've been able to listen and learn from the experiences our customers have had. I think that's an incredible advantage as we now firmly plant ourselves in the cloud DBAAS market alongside our robust Postgres capabilities that you experienced.Corey: The world isn't generating less data, and it's important that we're able to access that in a bunch of different ways. And the last time I really was playing with relational databases, you can view my understanding of it as Excel with a weirder interface, and you're mostly there. One thing that really struck me since the last time I went deep into database-land over in the Postgres-squeal world has been just the sheer variety of native data types that it winds up supporting. The idea of, “Here's some JSON. Take this and store it that way,” or it's GIS data that it can represent, or the idea of having data types that are beyond just string or var or whatever other somewhat limited boolean values or whatnot. Without having just that traditional list, which is of course all there as well. It also seems to have extensively improved its coverage that just can only hint to my small mind about these things and what sort of use cases people are really putting these things into.Ed: Yeah, I think this is one of Postgres' superpowers. And it started with Mike Stonebraker's original development of Postgres as an object-relational database. Mike is an adviser to EDB, which has been incredibly helpful as we've continued to evolve our thinking about what's possible in Postgres. But I think because of that core technology, or that core—because of that core technical capability within Postgres, we have been able to build a whole host of data types. And so now you see Postgres being used not just as the context of a traditional relational database, but we see it used as a time-series database. You pointed out a geospatial database, more and more is a document-oriented database with JSON and JSONB.These are all the things that make Postgres have much more universal appeal, universal appeal to developers—which is worth talking about in the recent StackOverflow developer survey, but we can come back to that—and I think universal applicability for new applications. This is what's bringing Postgres forward faster, unlike many of the specialty database companies that you mentioned earlier.Corey: Now, this is something that you can use for your traditional CRUD app, the my first hello world app that returns something from a database, yeah, that stuff works. But it also, for example, has [cyter 00:25:09] data types, where you can say, give me the results where the IP range contains this address, and it'll do that. Before that, you're trying to solve a whole bunch of very messy things in application logic that's generally awful. The database now does that for you automatically, and there's something—well, it would if I were smart and used it instead of storing it as strings because I make terrible life choices, but for sensible people, it solves a lot of those problems super well. And it's taken the idea of where logic should live in application versus database, and sort of turn a lot of those assumptions I was starting my career with on their head.Ed: Yeah, I think if you look now at the appeal of Postgres to developers, which we've paid a lot of attention to—one of our stated strategies at EDB is to make Postgres easier. That's been true for many years, so a drive for engineering and development here has been that call to action. And if you measure that, over time, we've been contributing—not alone, but contributing to making Postgres more approachable, easier to use, easier to engage with. Some of those things we do just through edb.com, and the way we handle EDB docs is a great example of that, and our developer advocacy and outreach into adjacent communities that care about Postgres. But here's where that's landed us. If you looked at the last Stack Overflow developer survey—the 2021 Stack Overflow developer survey, which I love because I think it's very independent-oriented—and they surveyed, I think this past year was 80,000 developers.Corey: Oh yeah, if Stack Overflow is captured by any particular constituency, it's got to be ‘Big Copy and Paste' that is really behind them. But yeah, other than the cabal of keyboard manufacturers for those copy-and-paste stories, yeah, they're fairly objective when it comes to stuff like this.Ed: And if you look at that survey, Corey, if you just took and summed it because it's helpful to sum it, most used, most loved, and most wanted database: Postgres wins. And I find it fascinating that if you—having been here, in this company for 13 years and watch the evolution from—you know, 13 years ago, Postgres needed help, both in terms of its awareness in the market and some technical capabilities it just lacked, we've come so far. For that to be the new standard for developers, I think, is a remarkable achievement. And I think it's a representation of why Postgres is doing so well in the market that we've long served, in the cloud market that we are now serving, and I think it speaks to what's ahead as a transformational database for the future.Corey: There really is something to be said for a technology as—please don't take this term the wrong way—old. As a relational database, Postgres has been around for a very long time, but it's also not your grandparents' Postgres. It is continuing to evolve. It continues to be there in a bunch of really interesting ways for developers in a variety of different capacities, and it's not the sort of thing that you're only using in, “Legacy environments,” quote-unquote. Instead, it's something that you'll see all over the place. It is rare that I see an environment that doesn't have Postgres in it somewhere these days.Ed: Yeah, I think quite the contrary to the old-school database, which I love that; I love that shade because when you step away from it, you realize, the Postgres community represents the very best of what's possible with open-source. And that's why Postgres continues to accelerate and move forward at the rate that it does. And obviously, we're proud to be a contributor to that, so we don't just watch that outcome happen; we're actually part of creating it. But I also think that when you see all that Postgres has become and where it's going, you really start to understand why the market is adopting open-source.Corey: It's one of those areas where even if some company comes out with something that is amazing and transformatively better, and you should jump into it with both feet and never look back, yeah, it turns out that it takes a long time to move databases, even when they're terrible. And you can lobby an awful lot of accusations at Postgres—or Postgres-squeal—but you can't call it terrible. It's used in enough interesting applications by enough large-scale companies out there—and small as well—that it's very hard to find a reason not to explore it. It's my default relational database when Route 53 loses steam. It just makes sense in a bunch of ways that other things really didn't for me before.Ed: Yeah, and I think we'll continue to see that. And we're just going to keep making Postgres better. And it gets better because of that intersection, as I mentioned, that intimate intersection between enterprise users, and the project, and the community, and the bridge that a company like EDB provides for that. That's why it'll get better faster; the breadth of use of Postgres will keep it accelerating. And I think it's different than many of the specialty databases.Look, I've been in open-source now for 20 years and it's intriguing to me how many new specialty open-source databases have come to market. We tend to forget the amount of roadkill we've had over the course of the past ten years of some of those open-source projects and companies. We certainly are tuned into some of the more prolific ones, even today. And I think again, here again, this is where Postgres shines, and where I think Postgres is a better call for a long-term. Just like Linux was.Corey: I want to thank you for taking so much time out of your day to talk to me about databases, which given my proclivities, is probably like pulling teeth for you. If people want to learn more, where can they find you?Ed: So, come to enterprisedb.com. You still get EnterpriseDB, Corey. Just come to enterprise—Corey: There we go. It's hidden in the URL, right in plain sight.Ed: Come to enterprisedb.com. You can learn all the things you need about the technology, and certainly more that we can do to help you.Corey: And we will, of course, put links to that in the [show notes 00:31:10]. Thank you once again for your time. I really do appreciate it.Ed: Thanks, Corey. My pleasure.Corey: Ed Boyajian, CEO of EDB. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a long angry comment because you are one of the two Amazonian developers working on open-source databases.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About KarthikKarthik was one of the original database engineers at Facebook responsible for building distributed databases including Cassandra and HBase. He is an Apache HBase committer, and also an early contributor to Cassandra, before it was open-sourced by Facebook. He is currently the co-founder and CTO of the company behind YugabyteDB, a fully open-source distributed SQL database for building cloud-native and geo-distributed applications.Links: Yugabyte community Slack channel: https://yugabyte-db.slack.com/ Distributed SQL Summit: https://distributedsql.org Twitter: https://twitter.com/YugaByte TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: You could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them I sent you and watch them wince—because everyone does when you bring up my name. Thats the glorious part of being me. Once again, you could build your own notification system but why on god's flat earth would you do that?Corey: This episode is sponsored in part by “you”—gabyte. Distributed technologies like Kubernetes are great, citation very much needed, because they make it easier to have resilient, scalable, systems. SQL databases haven't kept pace though, certainly not like no SQL databases have like Route 53, the world's greatest database. We're still, other than that, using legacy monolithic databases that require ever growing instances of compute. Sometimes we'll try and bolt them together to make them more resilient and scalable, but let's be honest it never works out well. Consider Yugabyte DB, its a distributed SQL database that solves basically all of this. It is 100% open source, and there's not asterisk next to the “open” on that one. And its designed to be resilient and scalable out of the box so you don't have to charge yourself to death. It's compatible with PostgreSQL, or “postgresqueal” as I insist on pronouncing it, so you can use it right away without having to learn a new language and refactor everything. And you can distribute it wherever your applications take you, from across availability zones to other regions or even other cloud providers should one of those happen to exist. Go to yugabyte.com, thats Y-U-G-A-B-Y-T-E dot com and try their free beta of Yugabyte Cloud, where they host and manage it for you. Or see what the open source project looks like—its effortless distributed SQL for global apps. My thanks to Yu—gabyte for sponsoring this episode.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode comes from the place where a lot of my episodes do: I loudly and stridently insist that Route 53—or DNS in general—is the world's greatest database, and then what happens is a whole bunch of people who work at database companies get upset with what I've said. Now, please don't misunderstand me; they're wrong, but I'm thrilled to have them come on and demonstrate that, which is what's happening today. My guest is CTO and co-founder of Yugabyte. Karthik Ranganathan, thank you so much for spending the time to speak with me today. How are you?Karthik: I'm doing great. Thanks for having me, Corey. We'll just go for YugabyteDB being the second-best database. Let's just keep the first [crosstalk 00:01:13]—Corey: Okay. We're all fighting for number two, there. And besides, number two tries harder. It's like that whole branding thing from years past. So, you were one of the original database engineers at Facebook, responsible for building a bunch of nonsense, like Cassandra and HBase. You were an HBase committer, early contributor to Cassandra, even before it was open-sourced.And then you look around and said, “All right, I'm going to go start a company”—roughly around 2016, if memory serves—“And I'm going to go and build a database and bring it to the world.” Let's start at the beginning. Why on God's flat earth do we need another database?Karthik: Yeah, that's the question. That's the million-dollar question isn't it, Corey? So, this is one, fortunately, that we've had to answer so many times from 2016, that I guess we've gotten a little good at it. So, here's the learning that a lot of us had from Facebook: we were the original team, like, all three of us founders, we met at Facebook, and we not only build databases, we also ran them. And let me paint a picture.Back in 2007, the public cloud really wasn't very common, and people were just going into multi-region, multi-datacenter deployments, and Facebook was just starting to take off, to really scale. Now, forward to 2013—I was there through the entire journey—a number of things happened in Facebook: we saw the rise of the equivalent of Kubernetes which was internally built; we saw, for example, microservice—Corey: Yeah, the Tupperware equivalent, there.Karthik: Tupperware, exactly. You know the name. Yeah, exactly. And we saw how we went from two data centers to multiple data centers, and nearby and faraway data centers—zones and regions, what do you know as today—and a number of such technologies come up. And I was on the database side, and we saw how existing databases wouldn't work to distribute data across nodes, failover, et cetera, et cetera.So, we had to build a new class of databases, what we now know is NoSQL. Now, back in Facebook, I mean, the typical difference between Facebook and an enterprise at large is Facebook has a few really massive applications. For example, you do a set of interactions, you view profiles, you add friends, you talk with them, et cetera, right? These are supermassive in their usage, but they were very few in their access patterns. At Facebook, we were mostly interested in dealing with scale and availability.Existing databases couldn't do it, so we built NoSQL. Now, forward a number of years, I can't tell you how many times I've had conversations with other people building applications that will say, “Hey, can I get a secondary index on the SQL database?” Or, “How about that transaction? I only need it a couple of times; I don't need it all the time, but could you, for example, do multi-row transactions?” And the answer was always, “Not,” because it was never built for that.So today, what we're seeing is that transactional data and transactional applications are all going cloud-native, and they all need to deal with scale and availability. And so the existing databases don't quite cut it. So, the simple answer to why we need it is we need a relational database that can run in the cloud to satisfy just three properties: it needs to be highly available, failures or no, upgrades or no, it needs to be available; it needs to scale on demand, so simply add or remove nodes and scale up or down; and it needs to be able to replicate data across zones, across regions, and a variety of different topologies. So availability, scale, and geographic distribution, along with retaining most of the RDBMS features, the SQL features. That's really what the gap we're trying to solve.Corey: I don't know that I've ever told this story on the podcast, but I want to say it was back in 2009. I flew up to Palo Alto and interviewed at Facebook, and it was a different time, a different era; it turns out that I'm not as good on the whiteboard as I am at running my mouth, so all right, I did not receive an offer, but I think everyone can agree at this point that was for the best. But I saw one of the most impressive things I've ever seen, during a part of that interview process. My interview is scheduled for a conference room for must have been 11 o'clock or something like that, and at 10:59, they're looking at their watch, like, “Hang on ten seconds.” And then the person I was with reached out to knock on the door to let the person know that their meeting was over and the door opened.So, it's very clear that even in large companies, which Facebook very much was at the time, people had synchronized clocks. This seems to be a thing, as I've learned from reading the parts that I could understand of the Google Spanner paper: when you're doing distributed databases, clocks are super important. At places like Facebook, that is, I'm not going to say it's easy, let's be clear here. Nothing is easy, particularly at scale, but Facebook has advantages in that they can mandate how clocks are going to be handled throughout every piece of their infrastructure. You're building an open-source database and you can't guarantee in what environment and on what hardware that's going to run, and, “You must have an atomic clock hooked up,” is not something you're generally allowed to tell people. How do you get around that?Karthik: That's a great question. Very insightful, cutting right to the chase. So, the reality is, we cannot rely on atomic clocks, we cannot mandate our users to use them, or, you know, we'd not be very popularly used in a variety of different deployments. In fact, we also work in on-prem private clouds and hybrid deployments where you really cannot get these atomic clocks. So, the way we do this is we come up with other algorithms to make sure that we're able to get the clocks as synchronized as we can.So, think about at a higher level; the reason Google uses atomic clocks is to make sure that they can wait to make sure every other machine is synchronized with them, and the wait time is about seven milliseconds. So, the atomic clock service, or the true time service, says no two machines are farther apart than about seven milliseconds. So, you just wait for seven milliseconds, you know everybody else has caught up with you. And the reason you need this is you don't want to write on a machine, you don't want to write some data, and then go to a machine that has a future or an older time and get inconsistent results. So, just by waiting seven milliseconds, they can ensure that no one is going to be older and therefore serve an older version of the data, so every write that was written on the other machine see it.Now, the way we do this is we only have NTP, the Network Time Protocol, which does synchronization of time across machines, except it takes 150 to 200 milliseconds. Now, we wouldn't be a very good database, if we said, “Look, every operation is going to take 150 milliseconds.” So, within these 150 milliseconds, we actually do the synchronization in software. So, we replaced the notion of an atomic clock with what is called a hybrid logical clock. So, one part using NTP and physical time, and another part using counters and logical time and keep exchanging RPCs—which are needed in the course of the database functioning anyway—to make sure we start normalizing time very quickly.This in fact has some advantages—and disadvantages, everything was a trade-offs—but the advantage it has over a true time-style deployment is you don't even have to wait that seven milliseconds in a number of scenarios, you can just instantly respond. So, that means you get even lower latencies in some cases. Of course, the trade-off is there are other cases where you have to do more work, and therefore more latency.Corey: The idea absolutely makes sense. You started this as an open-source project, and it's thriving. Who's using it and for what purposes?Karthik: Okay, so one of the fundamental tenets of building this database—I think back to your question of why does the world need another database—is that the hypothesis is not so much the world needs another database API; that's really what users complain against, right? You create a new API and—even if it's SQL—and you tell people, “Look. Here's a new database. It does everything for you,” it'll take them two years to figure out what the hell it does, and build an app, and then put it in production, and then they'll build a second and a third, and then by the time they hit the tenth app, they find out, “Okay, this database cannot do the following things.” But you're five years in; you're stuck, you can only add another database.That's really the story of how NoSQL evolved. And it wasn't built as a general-purpose database, right? So, in the meanwhile, databases like Postgres, for example, have been around for so long that they absorb and have such a large ecosystem, and usage, and people who know how to use Postgres and so on. So, we made the decision that we're going to keep the database API compatible with known things, so people really know how to use them from the get-go and enhance it at a lower level to make a cloud-native. So, what is YugabyteDB do for people?It is the same as Postgres and Postgres features of the upper half—it reuses the code—but it is built on the lower half to be [shared nothing 00:09:10], scalable, resilient, and geographically distributed. So, we're using the public cloud managed database context, the upper half is built like Amazon Aurora, the lower half is built like Google Spanner. Now, when you think about workloads that can benefit from this, we're a transactional database that can serve user-facing applications and real-time applications that have lower latency. So, the best way to think about it is, people that are building transactional applications on top of, say, a database like Postgres, but the application itself is cloud-native. You'd have to do a lot of work to make this Postgres piece be highly available, and scalable, and replicate data, and so on in the cloud.Well, with YugabyteDB, we've done all that work for you and it's as open-source as Postgres, so if you're building a cloud-native app on Postgres that's user-facing or transactional, YugabyteDB takes care of making the database layer behave like Postgres but become cloud-native.Corey: Do you find that your users are using the same database instance, for lack of a better term? I know that instance is sort of a nebulous term; we're talking about something that's distributed. But are they having database instances that span multiple cloud providers, or is that something that is more talk than you're actually seeing in the wild?Karthik: So, I'd probably replace the word ‘instance' with ‘cluster', just for clarity, right?Corey: Excellent. Okay.Karthik: So, a cluster has a bunch—Corey: I concede the point, absolutely.Karthik: Okay. [laugh]. Okay. So, we'll still keep Route 53 on top, though, so it's good. [laugh].Corey: At that point, the replication strategy is called a zone transfer, but that's neither here nor there. Please, by all means, continue.Karthik: [laugh]. Okay. So, a cluster database like YugabyteDB has a number of instances. Now, I think the question is, is it theoretical or real? What we're seeing is, it is real, and it is real perhaps in slightly different ways than people imagine it to be.So, I'll explain what I mean by that. Now, there's one notion of being multi-cloud where you can imagine there's like, say, the same cluster that spans multiple different clouds, and you have your data being written in one cloud and being read from another. This is not a common pattern, although we have had one or two deployments that are attempting to do this. Now, a second deployment shifted once over from there is where you have your multiple instances in a single public cloud, and a bunch of other instances in a private cloud. So, it stretches the database across public and private—you would call this a hybrid deployment topology—that is more common.So, one of the unique things about YugabyteDB is we support asynchronous replication of data, just like your RDBMSs do, the traditional RDBMSs. In fact, we're the only one that straddles both synchronous replication of data as well as asynchronous replication of data. We do both. So, once shifted over would be a cluster that's deployed in one of the clouds but an asynchronous replica of the data going to another cloud, and so you can keep your reads and writes—even though they're a little stale, you can serve it from a different cloud. And then once again, you can make it an on-prem private cloud, and another public cloud.And we see all of those deployments, those are massively common. And then the last one over would be the same instance of an app, or perhaps even different applications, some of them running on one public cloud and some of them running on a different public cloud, and you want the same database underneath to have characteristics of scale and failover. Like for example, if you built an app on Spanner, what would you do if you went to Amazon and wanted to run it for a different set of users?Corey: That is part of the reason I tend to avoid the idea of picking a database that does not have at least theoretical exit path because reimagining your entire application's data model in order to migrate is not going to happen, so—Karthik: Exactly.Corey: —come hell or high water, you're stuck with something like that where it lives. So, even though I'm a big proponent as a best practice—and again, there are exceptions where this does not make sense, but as a general piece of guidance—I always suggest, pick a provider—I don't care which one—and go all-in. But that also should be shaded with the nuance of, but also, at least have an eye toward theoretically, if you had to leave, consider that if there's a viable alternative. And in some cases in the early days of Spanner, there really wasn't. So, if you needed that functionality, okay, go ahead and use it, but understand the trade-off you're making.Now, this really comes down to, from my perspective, understand the trade-offs. But the reason I'm interested in your perspective on this is because you are providing an open-source database to people who are actually doing things in the wild. There's not much agenda there, in the same way, among a user community of people reporting what they're doing. So, you have in many ways, one of the least biased perspectives on the entire enterprise.Karthik: Oh, yeah, absolutely. And like I said, I started from the least common to the most common; maybe I should have gone the other way. But we absolutely see people that want to run the same application stack in multiple different clouds for a variety of reasons.Corey: Oh, if you're a SaaS vendor, for example, it's, “Oh, we're only in this one cloud,” potential customers who in other clouds say, “Well, if that changes, we'll give you money.” “Oh, money. Did you say ‘other cloud?' I thought you said something completely different. Here you go.” Yeah, you've got to at some point. But the core of what you do, beyond what it takes to get that application present somewhere else, you usually keep in your primary cloud provider.Karthik: Exactly. Yep, exactly. Crazy things sometimes dictate or have to dictate architectural decisions. For example, you're seeing the rise of compliance. Different countries have different regulatory reasons to say, “Keep my data local,” or, “Keep some subset of data are local.”And you simply may not find the right cloud providers present in those countries; you may be a PaaS or an API provider that's helping other people build applications, and the applications that the API provider's customers are running could be across different clouds. And so they would want the data local, otherwise, the transfer costs would be really high. So, a number of reasons dictate—or like a large company may acquire another company that was operating in yet another cloud; everything else is great, but they're in another cloud; they're not going to say, “No because you're operating on another cloud.” It still does what they want, but they still need to be able to have a common base of expertise for their app builders, and so on. So, a number of things dictate why people started looking at cross-cloud databases with common performance and operational characteristics and security characteristics, but don't compromise on the feature set, right?That's starting to become super important, from our perspective. I think what's most important is the ability to run the database with ease while not compromising on your developer agility or the ability to build your application. That's the most important thing.Corey: When you founded the company back in 2016, you are VC-backed, so I imagine your investor pitch meetings must have been something a little bit surreal. They ask hard questions such as, “Why do you think that in 2016, starting a company to go and sell databases to people is a viable business model?” At which point you obviously corrected them and said, “Oh, you misunderstand. We're building an open-source database. We're not charging for it; we're giving it away.”And they apparently said, “Oh, that's more like it.” And then invested, as of the time of this recording, over $100 million in your company. Let me to be the first to say there are aspects of money that I don't fully understand and this is one of those. But what is the plan here? How do you wind up building a business case around effectively giving something away for free?And I want to be clear here, Yugabyte is open-source, and I don't have an asterisk next to that. It is not one of those ‘source available' licenses, or ‘anyone can do anything they want with it except Amazon' or ‘you're not allowed to host it and offer it as a paid service to other people.' So, how do you have a business, I guess is really my question here?Karthik: You're right, Corey. We're 100% open-source under Apache 2.0—I mean the database. So, our theory on day one—I mean, of course, this was a hard question and people did ask us this, and then I'll take you guys back to 2016. It was unclear, even as of 2016, if open-source companies were going to succeed. It was just unclear.And people were like, “Hey, look at Snowflake; it's a completely managed service. They're not open-source; they're doing a great job. Do you really need open-source to succeed?” There were a lot of such questions. And every company, every project, every space has to follow its own path, just applying learnings.Like for example, Red Hat was open-source and that really succeeded, but there's a number of others that may or may not have succeeded. So, our plan back then was to tread the waters carefully in the sense we really had to make sure open-source was the business model we wanted to go for. So, under the advisement from our VCs, we said we'd take it slowly; we want to open-source on day one. We've talked to a number of our users and customers and make sure that is indeed the path we've wanted to go. The conversations pretty clearly told us people wanted an open database that was very easy for them to understand because if they are trusting their crown jewels, their most critical data, their systems of record—this is what the business depends on—into a database, they sure as hell want to have some control over it and some transparency as to what goes on, what's planned, what's on the roadmap. “Look, if you don't have time, I will hire my people to go build for it.” They want it to be able to invest in the database.So, open-source was absolutely non-negotiable for us. We tried the traditional technique for a couple of years of keeping a small portion of the features of the database itself closed, so it's what you'd call ‘open core.' But on day one, we were pretty clear that the world was headed towards DBaaS—Database as a Service—and make it really easy to consume.Corey: At least the bad patterns as well, like, “Oh, if you want security, that's a paid feature.”Karthik: Exactly.Corey: No. That is not optional. And the list then of what you can wind up adding as paid versus not gets murky, and you're effectively fighting your community when they try and merge some of those features in and it just turns into a mess.Karthik: Exactly. So, it did for us for a couple of years, and then we said, “Look, we're not doing this nonsense. We're just going to make everything open and just make it simple.” Because our promise to the users was, we're building everything that looks like Postgres, so it's as valuable as Postgres, and it'll work in the cloud. And people said, “Look, Postgres is completely open and you guys are keeping a few features not open. What gives?”And so after that, we had to concede the point and just do that. But one of the other founding pieces of a company, the business side, was that DBaaS and ability to consume the database is actually far more critical than whether the database itself is open-source or not. I would compare this to, for example, MySQL and Postgres being completely open-source, but you know, Amazon's Aurora being actually a big business, and similarly, it happens all over the place. So, it is really the ability to consume and run business-critical workloads that seem to be more important for our customers and enterprises that paid us. So, the day-one thesis was, look, the world is headed towards DBaaS.We saw that already happen with inside Facebook; everybody was automated operations, simplified operations, and so on. But the reality is, we're a startup, we're a new database, no one's going to trust everything to us: the database, the operations, the data, “Hey, why don't we put it on this tiny company. And oh, it's just my most business-critical data, so what could go wrong?” So, we said we're going to build a version of our DBaaS that is in software. So, we call this Yugabyte Platform, and it actually understands public clouds: it can spin up machines, it can completely orchestrate software installs, rolling upgrades, turnkey encryption, alerting, the whole nine yards.That's a completely different offering from the database. It's not the database, it's just on top of the database and helps you run your own private cloud. So, effectively if you install it on your Amazon account or your Google account, it will convert it into what looks like a DynamoDB, or a Spanner, or what have you with you, with Yugabyte as DB as the database inside. So, that is our commercial product; that's source available and that's what we charge for. The database itself, completely open.Again, the other piece of the thinking is, if we ever charge too much, our customers have the option to say, “Look, I don't want your DBaaS thing; I'm going to the open-source database and we're fine with that.” So, we really want to charge for value. And obviously, we have a completely managed version of our database as well. So, we reuse this platform for our managed version, so you can kind of think of it as portability, not just of the database but also of the control plane, the DBaaS plane.They can run it themselves, we can run it for them, they could take it to a different cloud, so on and so forth.Corey: I like that monetization model a lot better than a couple of others. I mean, let's be clear here, you've spent a lot of time developing some of these concepts for the industry when you were at Facebook. And because at Facebook, the other monetization models are kind of terrifying, like, “Okay. We're going to just monetize the data you store in the open-source database,” is terrifying. Only slightly less would be the Google approach of, “Ah, every time you wind up running a SQL query, we're going to insert ads.”So, I like the model of being able to offer features that only folks who already have expensive problems with money to burn on those problems to solve them will gravitate towards. You're not disadvantaging the community or the small startup who wants it but can't afford it. I like that model.Karthik: Actually, the funny thing is, we are seeing a lot of startups also consume our product a lot. And the reason is because we only charge for the value we bring. Typically the problems that a startup faces are actually much simpler than the complex requirements of an enterprise at scale. They are different. So, the value is also proportional to what they want and how much they want to consume, and that takes care of itself.So, for us, we see that startups, equally so as enterprises, have only limited amount of bandwidth. They don't really want to spend time on operationalizing the database, especially if they have an out to say, “Look, tomorrow, this gets expensive; I can actually put in the time and money to move out and go run this myself. Why don't I just get started because the budget seems fine, and I couldn't have done it better myself anyway because I'd have to put people on it and that's more expensive at this point.” So, it doesn't change the fundamentals of the model; I just want to point out, both sides are actually gravitating to this model.Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: A number of different surveys have come out that say overwhelmingly companies prefer open-source databases, and this is waved around as a banner of victory by a lot of—well, let's be honest—open-source database companies. I posit that is in fact crap and also bad data because what the open-source purists—of which I admit, I used to be one, and now I solve business problems instead—believe that people are talking about freedom, and choice, and the rest. In practice, in my experience, what people are really distilling that down to is they don't want a commercial database. And it's not even about they're not willing to pay money for it, but they don't want to have a per-core licensing challenge, or even having to track licensing of where it is installed and how, and wind up having to cut checks for folks. For example, I'm going to dunk on someone because why not?Azure for a while has had this campaign that it is five times cheaper to run some Microsoft SQL workloads in Azure than it is on AWS as if this was some magic engineering feat of strength or something. It's absolutely not, it's that it is really expensive licensing-wise to run it on things that aren't Azure. And that doesn't make customers feel good. That's the thing they want to get away from, and what open-source license it is, and in many cases, until the source-available stuff starts trending towards, “Oh, you're going to pay us or you're not going to run it at all,” that scares the living hell out of people, then they don't actually care about it being open. So, at the risk of alienating, I'm sure, some of the more vocal parts of your constituency, where do you fall on that?Karthik: We are completely open, but for a few reasons right? Like, multiple different reasons. The debate of whether it purely is open or is completely permissible, to me, I tend to think a little more where people care about the openness more so than just the ability to consume at will without worrying about the license, but for a few different reasons, and it depends on which segment of the market you look at. If you're talking about small and medium businesses and startups, you're absolutely right; it doesn't matter. But if you're looking at larger companies, they actually care that, like for example, if they want a feature, they are able to control their destiny because you don't want to be half-wedded to a database that cannot solve everything, especially when the time pressure comes or you need to do something.So, you want to be able to control or to influence the roadmap of the project. You want to know how the product is built—the good and the bad—you want a lot of people testing the product and their feedback to come out in the open, so you at least know what's wrong. Many times people often feel like, “Hey, my product doesn't work in these areas,” is actually a bad thing. It's actually a good thing because at least those people won't try it and [laugh] they'll be safe. Customer satisfaction is more important than just the apparent whatever it is that you want to project about the product.At least that's what I've learned in all these years working with databases. But there's a number of reasons why open-source is actually good. There's also a very subtle reason that people may not understand which is that legal teams—engineering teams that want to build products don't want to get caught up in a legal review that takes many months to really make sure, look, this may be a unique version of a license, but it's not a license the legal team as seen before, and there's going to be a back and forth for many months, and it's just going to derail their product and their timelines, not because the database didn't do its job or because the team wasn't ready, but because the company doesn't know what the risk it'll face in the future is. There's a number of these aspects where open-source starts to matter for real. I'm not a purist, I would say.I'm a pragmatist, and I have always been, but I would say that a number of reasons why–you know, I might be sounding like a purist, but a number of reasons why a true open-source is actually useful, right? And at the end of the day, if we have already established, at least at Yugabyte, we're pretty clear about that, the value is in the consumption and is not in the tech if we're pretty clear about that. Because if you want to run a tier-two workload or a hobbyist app at home, would you want to pay for a database? Probably not. I just want to do something for a while and then shut it down and go do my thing. I don't care if the database is commercial or open-source. In that case, being open-source doesn't really take away. But if you're a large company betting, it does take away. So.Corey: Oh, it goes beyond that because it's not even, in the large company story, whether it costs money because regardless, I assure you, open-source is not free; the most expensive thing that we see in all of our customer accounts—again, our consultancy fixes AWS bills, an expensive problem that hits everyone—the environment in AWS is always less expensive than the people who are working on the environment. Payroll is an expense that dwarfs the AWS bill for anyone that is not a tiny startup that is still not paying a market-rate salary to its founders. It doesn't work that way. And the idea, for those folks is, not about the money, it's about the predictability. And if there's a 5x price hike from their database manager that suddenly completely disrupts their unit economic model, and they're in trouble. That's the value of open-source in that it can go anywhere. It's a form of not being locked into any vendor where it's hosted, as well as, now, no one company that has put it out there into the world.Karthik: Yeah, and the source-available license, we considered that also. The reason to vote against that was you can get into scenarios where the company gets competitive with his open-source site where the open-source wants a couple other features to really make it work for their own use case, like you know, case in point is the startup, but the company wants to hold those features for the commercial side, and now the startup has that 5x price jump anyway. So, at this point, it comes to a head-on where the company—the startup—is being charged not for value, but because of the monetization model or the business model. So, we said, “You know what? The best way to do this is to truly compete against open-source. If someone wants to operationalize the database, great. But we've already done it for you.” If you think that you can operationalize it at a lower cost than what we've done, great. That's fine.Corey: I have to ask, there has to have been a question somewhere along the way, during the investment process of, what if AWS moves into your market? And I can already say part of the problem with that line of reasoning is, okay, let's assume that AWS turns Yugabyte into a managed database offering. First, they're not going to be able to articulate for crap why you should use that over anything else because they tend to mumble when it comes time to explain what it is that they do. But it has to be perceived as a competitive threat. How do you think about that?Karthik: Yeah, this absolutely came up quite a bit. And like I said, in 2016, this wasn't news back then; this is something that was happening in the world already. So, I'll give you a couple of different points of view on this. The reason why AWS got so successful in building a cloud is not because they wanted to get into the database space; they simply wanted their cloud to be super successful and required value-added services like these databases. Now, every time a new technology shift happens, it gives some set of people an unfair advantage.In this case, database vendors probably didn't recognize how important the cloud was and how important it was to build a first-class experience on the cloud on day one, as the cloud came up because it wasn't proven, and they had twenty other things to do, and it's rightfully so. Now, AWS comes up, and they're trying to prove a point that the cloud is really useful and absolutely valuable for their customers, and so they start putting value-added services, and now suddenly you're in this open-source battle. At least that's how I would view that it kind of developed. With Yugabyte, obviously, the cloud's already here; we know on day one, so we're kind of putting out our managed service so we'll be as good as AWS or better. The database has its value, but the managed service has its own value, and so we'd want to make sure we provide at least as much value as AWS, but on any cloud, anywhere.So, that's the other part. And we also talked about the mobility of the DBaaS itself, the moving it to your private account and running the same thing, as well as for public. So, these are some of the things that we have built that we believe makes us super valuable.Corey: It's a better approach than a lot of your predecessor companies who decided, “Oh, well, we built the thing; obviously, we're going to be the best at running it. The end.” Because they dramatically sold AWS's operational excellence short. And it turns out, they're very good at running things at scale. So, that's a challenging thing to beat them on.And even if you're able to, it's hard to differentiate among the differences because at that caliber of operational rigor, it's one of those, you can only tell in the very niche cases; it's a hard thing to differentiate on. I like your approach a lot better. Before we go, I have one last question for you, and normally, it's one of those positive uplifting ones of what workloads are best for Yugabyte, but I think that's boring; let's be more cynical and negative. What workloads would run like absolute crap on YugabyteDB?Karthik: [laugh]. Okay, we do have a thing for this because we don't want to take on workloads and, you know, everybody have a bad experience around. So, we're a transactional database built for user-facing applications, real-time, and so on, right? We're not good at warehousing and analytic workloads. So, for example, if you were using a Snowflake or a Redshift, those workloads are not going to work very well on top of Yugabyte.Now, we do work with other external systems like Spark, and Presto, which are real-time analytic systems, but they translate the queries that the end-user have into a more operational type of query pattern. However, if you're using it straight-up for analytics, we're not a good bet. Similarly, there's cases where people want very high number of IOPS by reusing a cache or even a persistent cache. Amazon just came out with a [number of 00:31:04] persistent cache that does very high throughput and low-latency serving. We're not good at that.We can do reasonably low-latency serving and reasonably high IOPS at scale, but we're not the use case where you want to hit that same lookup over and over and over, millions of times in a second; that's not the use case for us. The third thing I'd say is, we're a system of record, so people care about the data they put, and they don't absolutely don't want to lose it and they want to show that it's transactional. So, if there's a workload where there's a lot of data and you're okay if you want to lose, and it's just some sensor data, and your reasoning is like, “Okay, if I lose a few data points, it's fine.” I mean, you could still use us, but at that point you'd really have to be a fanboy or something for Yugabyte. I mean, there's other databases that probably do it better.Corey: Yeah, that's the problem is whenever someone says, “Oh, yeah. Database”—or any tool that they've built—“Like, this is great.” “What workloads is it not a fit for?” And their answer is, “Oh, nothing. It's perfect for everything.”Yeah, I want to believe you, but my inner bullshit sense is tingling on that one because nothing's fit for all purposes; it doesn't work that way. Honestly, this is going to be, I guess, heresy in the engineering world, but even computers aren't always the right answer for things. Who knew?Karthik: As a founder, I struggled with this answer a lot, initially. I think the problem is, when you're thinking about a problem space, that's all you're thinking about, you don't know what other problem spaces exist, and when you are asked the question, “What workloads is it a fit for?” At least I used to say, initially, “Everything,” because I'm only thinking about that problem space as the world, and it's fit for everything in that problem space, except I don't know how to articulate the problem space—Corey: Right—Karthik: —[crosstalk 00:32:33]. [laugh].Corey: —and at some point, too, you get so locked into one particular way of thinking that the world that people ask about other cases like, “Oh, that wouldn't count.” And then your follow-up question is, “Wait, what's a bank?” And it becomes a different story. It's, how do you wind up reasoning about these things? I want to thank you for taking all the time you have today to speak with me. If people want to learn more about Yugabyte—either the company or the DB—how can they do that?Karthik: Yeah, thank you as well for having me. I think to learn about Yugabyte, just come join our community Slack channel. There's a lot of people; there's, like, over 3000 people. They're all talking interesting questions. There's a lot of interesting chatter on there, so that's one way.We have an industry-wide event, it's called the Distributed SQL Summit. It's coming up September 22nd, 23rd, I think a couple of days; it's a two-day event. That would be a great place to actually learn from practitioners, and people building applications, and people in the general space and its adjacencies. And it's not necessarily just about Yugabyte; it's generally about distributed SQL databases, in general, hence it's called the Distributed SQL Summit. And then you can ask us on Twitter or any of the usual social channels as well. So, we love interaction, so we are pretty open and transparent company. We love to talk to you guys.Corey: Well, thank you so much for taking the time to speak with me. Well, of course, throw links to that into the [show notes 00:33:43]. Thank you again.Karthik: Awesome. Thanks a lot for having me. It was really fun. Thank you.Corey: Likewise. Karthik Ranganathan, CTO, and co-founder of YugabyteDB. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment, halfway through realizing that I'm not charging you anything for this podcast and converting the angry comment into a term sheet for $100 million investment.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

The transition of @MongoDB from an open source project to commercially successful public company to cloud provider has been an interesting transition. One that many other software companies are looking to emulate. SHOW: 550CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:Datadog Synthetic Monitoring: Frontend and Backend Modern MonitoringStart detecting user-facing issues with API and browser tests with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt.CBT Nuggets: Expert IT Training for individuals and teamsSign up for a CBT Nuggets Free Learner account AWS Data Backup for Dummies (Veeam)Choose Your Own Cloud Adventure with Veeam and AWSSHOW NOTES:History of MongoDB (wikipedia)MongoDB Atlas is launched (DBaaS) - 2016Amazon launches DocumentDB (with MongoDB compatibility) - 2019MongoDB IPO - 2019SaaS and Moving Downmarket - MongoDB's TransformationEvolution of Commercial OSS (Cloudcast Eps.492)How Cloud is Changing OSS Licensing (Cloudcast Eps.493) FROM OPEN TO COMMERCIAL TO IPO TO CLOUDMany software companies are trying to make the evolution from customer-operated to cloud-operated business models. MongoDB is an early lighthouse is showing the blueprint for success. CHANGING (OR GROWING NEW) MARKETS IS VERY DIFFICULTSolve a technical problemCreate a unique value proposition (simplicity)[Marketing] Create (and lead) a growing community of users - via open source[Monetization] Create open-core features to differentiate and solve unique problems [New GTM, New Markets] Evolve the product to new delivery modelsGrow into new markets, through different customer engagement models FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

The increasing complexity in the IT landscape is driving more and more organizations to look to managed services to accomplish their business objectives. Hear from Chris Fuller, Principal Architect for MSPs, Americas, and Shobhit Bhutani, Global Partner & Solutions Marketing Manager, MSPs, about how MSPs are expanding solution capabilities and how Pure enables MSPs to drive out risk and deliver breakthrough outcomes for end users. Chris explains the differentiated nature of Pure's MSP programs, the relationships with key service providers, and how Pure helps MSPs deliver value-added services for hybrid cloud, DBaaS, VMware, analytics, data protection and even Ransomware mitigation as a service. For more information: https://www.purestorage.com/partners/managed-service-providers.html

Welcome to the second episode in a series we're calling The Road to Atlas.  In this series, my co-hosts, Jesse Hall, and Nic Raboy will talk with some of the people responsible for building, and launching the platform that helped to transform MongoDB as a company. beginning with Episode 1, the On ramp to Atlas we chatted with Sahir Azam, Chief Product Officer, and Andrew Davidson, VP of Product about the strategic shift from a software company to a software as a service business. In this, episode 2, Zero to Database as a Service, we'll chat with Cailin Nelson, Executive Vice President of Cloud, and Cory Mintz, Vice President of Engineering - about Atlas as a product and how it was built and launched. Coming up In episode 3, we'll Go Mobile, talking with Alexander Stigsen, Founder of the Realm Mobile Database which has become a part of the Atlas Platform.  And finally, In episode 4, we'll wrap the series up with a panel discussion and review some of our valued customer comments about the platform. 

Sergey Pronin ( Percona Product Owner for Percona's Kubernetes operators ) visits with the HOSS again talking about the latest releases as Percona adds functionality to Percona's MongoDB and MySQL Operators ( Also coming soon a PostgreSQL Operator! ).

OpenStack was going to create an open source alternative to AWS, as well as displace VMware in the Enterprise. But change is never easy, and some things didn't go as planned. Looking back, what can we learn from the lessons of OpenStack? SHOW: 489SHOW SPONSOR LINKS:BMC Wants to Know if your business is on its A-GameBMC Autonomous Digital EnterpriseCLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW NOTES:Eucalyptus Cloud (2006)CloudStack (2008)History of OpenStackOpenStack ProjectsOpenStack accepting VMware was a Mistake (Mirantis, 2012)The trouble with OpenStack (Simon Wardley, 2013)OpenStack’s future depends on embracing AWS, Now (Cloudscaling, 2013)OpenStack adopts the “Big Tent” model (2015)OpenStack Summit 2016 (Austin) - The focus moves to TelcoHOW DID OPENSTACK EVOLVE?An open source, programmable cloud infrastructure. Eucalyptus and CloudStack existed prior to OpenStack. Created as a partnership between NASA (Nova) and Rackspace (Swift). API-driven, software-defined infrastructureEvery vendor (HW and SW) was on-board: the anti-VMware projectOpenStack Foundation was created - control was maintained by Rackspace (initially). Focus was split on building an AWS-alternative &/or a VMware-alternativeWas it an integrated platform, or independent projects, or a combination? What defined something as “OpenStack”? How do you upgrade OpenStack? The scope eventually got too big - way behind an IaaS (PaaS, DBaaS, Hadoop, etc.)Cloud Foundry, OpenShift launched in 2011Threats from Hadoop companiesVMware admins didn’t know how to use python. AWS admins wanted AWS APIsWhere were the customers? LESSONS LEARNED FOR THE FUTUREIndependent governance body; leverage the Linux foundation (events, infrastructure, etc,)Focus on enabling something new (cloud-native apps, more flexible than PaaS), not replacing something existingEnable early customers, and remain customer focused. FEEDBACK?Email: show at thecloudcast dot netTwitter: @thecloudcastnet

SHOW: Season 1, Show 6OVERVIEW: From the creators of the Internet's #1 Cloud Computing podcast, The Cloudcast, Aaron Delp (@aarondelp) and Brian Gracely (@bgracely) introduce this new podcast,  Cloudcast Basics.  What does PaaS mean in the cloud? Developers write code and push it to production. Operations is managed by the platform. Simple way to get to all the services an application needs (database, queues, load-balancing, high availability, authentication, etc.)How are PaaS services allocated? Typically by application, or volume of consumption (memory usage, # of transactions, etc.)How were PaaS services allocated before cloud computing? Manually. Developers often had to know about infrastructure, security, availability, etc.What does the cloud computing provider do with a PaaS offering (responsibilities vs. customer responsibilities? Lots of variety, depending on the serviceWhy are there so many variations of PaaS and Application Services? Evolution of understanding developer needs - how “opinionated” to be vs. giving developers more granular control.Does it matter where the PaaS is located? How do clouds organize PaaS (availability zones, regions, etc.)? Usually most of this is hidden, beyond the geographic region. How much do PaaS services cost in the cloud? What are the various ways you can buy PaaS? Examples:AWS Proton - https://aws.amazon.com/proton/Azure Service Fabric - https://azure.microsoft.com/en-us/services/service-fabric/Google AppEngine - https://cloud.google.com/appengineOracle Cloud PaaS - https://www.oracle.com/application-development/Heroku - https://www.heroku.com/Red Hat OpenShift Dedicated - https://www.openshift.com/products/dedicated/SUBSCRIBE: Please subscribe anywhere you get podcasts (Apple Podcasts, Google Podcasts, Spotify, Stitcher, Amazon Music, Pandora, etc.).CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwLEARNING CLOUD COMPUTING:Here are some great places to begin your cloud journey, if you're interested in getting hands-on experience with the technology, or you'd like to build your skills towards a certification. CBT Nuggets - Training and CertificationsA Cloud Guru - Training and CertificationsCloud Academy - Training and CertificationsKatakoda - Self-Paced, Interactive LearningGitHub - Code Samples and CollaborationFEEDBACK?Web: Cloudcast Basics Email: show at cloudcastbasics dot netTwitter: @cloudcastbasics

EP74 - O que é banco de dados como serviço (DBaaS) ? Entre no nosso canal do Telegram para receber conteúdos Exclusivos sobre Banco de dados Oracle: https://t.me/joinchat/AAAAAEb7ufK-90djaVuR4Q

Our DBAle hosts celebrate this milestone quarter century by sampling Bonnie Scotland’s finest brews, provided by the French. Chris tells Chris exactly where he can shove his SQL Server Databases as they talk acronyms: IaaS, PaaS, DBaaS, RDS and AWS. While, in The News we take off with sky high ICO fines, Monitoring RDS and the importance of Aardvarks in Redgate's recent 21st birthday.  So, grab yourself a beer and tune in – cheers.

Distributed databases on kubernetes And we just keep rolling along! Round 3 of the data on kubernetes community meetup! This time we will be talking with Nikhil Chandrappa Lead Software engineer at YugabyteDB. We will take a Practical look at running distributed SQL on Kubernetes using YugabyteDB Key takeaways: - Introduction to YugabyteDB Distributed SQL databases and its design principles - Design considerations for operationalizing Distributed SQL on Kubernetes - Deployment strategies for clustered Databases - Storage orchestration on Kubernetes - Yugabyte's approach for DBAAS on Kubernetes - DB Creation, Scale up / Scale down - Implementing Day 2 operations for distributed SQL databases - upgrades, backups, and monitoring - Distributed SQL Demo: A real-world e-commerce application Abstract This talk is targeted towards cloud-native developers and architects looking to deploy the operational database on Kubernetes. We are going to walk you through the design decisions YugabyteDB's team took when architecting the database as a service on Kubernetes. We are going to cover concepts related to Kubernetes Volume provisioning, pod placement strategies for data resilience/High availability, and how cluster events are used for reconciling the k8s workloads during day 2 operations like upgrades, scale-up/down. Bio: Nikhil is an ecosystem engineer at Yugabyte. He is leading the efforts on YugabyteDB integrations with open source developer tools like GraphQL, Spring Data, R2DBC, and Kubernetes. He also works with the developer community on the adoption of Distributed SQL databases in cloud native apps. Before joining Yugabyte, he worked as a senior data engineer at Pivotal which is now part of VMware Tanzu, championing the cloud native data APIs and in-memory data grids for fortune 500 customers. He has presented at major developer conferences, SpringOne Platform, PostgreSQL conf, JPMC tech fest. He is originally from Mysore, India, and has graduated with a masters degree in Computer Engineering from Syracuse University. I am currently looking for speakers who can talk about things such as operators, databases, multicloud/hybrid, or anything else that could be interesting for the SRE engineering crowd. Join our slack: https://join.slack.com/t/dokcommunity/shared_invite/zt-g3ui5r0g-jDKz5dhh2W1ayElqwKYYAg Follow us on Twitter: @dokcommunity Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Nikhil on Linkedin: https://www.linkedin.com/in/nikhilmc/ This meetup is sponsored by MayaData, which helped start the DOK.community and remains an active supporter. MayaData sponsors two Cloud Native Computing Foundation (CNCF) projects, OpenEBS - the leading open-source container attached storage solution - and Litmus - the leading Kubernetes native chaos engineering project, which was recently donated to the CNCF as a Sandbox project. As of June 2020, MayaData is the sixth-largest contributor to CNCF projects. Well-known users of MayaData products include the CNCF itself, Bloomberg, Comcast, Arista, Orange, Intuit, and others. Check out more info at https://mayadata.io/ ||SHOW NOTES|| Slides: https://docs.google.com/presentation/d/1MOYgKm3EuhQHY2ryxSC3qFId2snCI0nPzdKa28wL4EI/edit?usp=sharing YugaByte CTO's talk about logical clocks https://blog.yugabyte.com/distributed-postgresql-on-a-google-spanner-architecture-storage-layer/ Link to Yugabyte hiring page https://blog.yugabyte.com/insert-into-yugabyte-were-hiring-july-2020-edition/ Getting started with YugabyteDB - https://download.yugabyte.com/ Learn more about the internals of Distributed SQL https://blog.yugabyte.com/distributed-postgresql-on-a-google-spanner-architecture-query-layer/ Learn more about Microservices + YugabyteDB https://www.yugabyte.com/spring/

In this episode of Scaling Postgres, we discuss how to show live query plans, the importance of atomic operations for scaling out, configuration options and DBaaS migrations. Subscribe at https://www.scalingpostgres.com to get notified of new episodes. Links for this episode: https://www.cybertec-postgresql.com/en/pg_show_plans-watching-execution-plans-in-postgresql-live/ https://www.highgo.ca/2020/03/26/optimizing-sql-step-1-explain-in-postgresql-part-1/ https://www.highgo.ca/2020/03/24/atomic-commit-and-atomic-visibility-for-postgresql-explained/ https://mydbanotebook.org/post/troubleshooting-02/ https://www.youtube.com/watch?v=13d4BDYSYyM https://www.percona.com/blog/2020/03/25/migrating-a-postgresql-database-between-dbaas-providers/ https://www.cybertec-postgresql.com/en/embedded-sql-in-c-for-postgresql-with-ecpg-blog/ https://www.highgo.ca/2020/03/24/logical-replication-between-postgresql-and-mongodb/ https://www.2ndquadrant.com/en/blog/developing-postgresql-windows-part-3/ https://www.highgo.ca/2020/03/26/postgresql-gssapi-authentication-with-kerberos-part-2-postgresql-configuration/ https://postgresql.life/post/dave_cramer/ https://info.crunchydata.com/blog/tile-serving-with-dynamic-geometry  

En este episodio nos enfocamos en las prestaciones y concepción de las bases de datos as a service (DBaaS), para qué sirve, en qué se basa, para qué tipo de empresas funciona este modelo y cuáles son los principales beneficios de un ambiente DBaaS.Estos son los enlaces a los temas de los que hemos hablado y a los productos mencionados:Alluxio: https://www.alluxio.io/Pachyderm: https://www.pachyderm.com/Docker: https://www.docker.comMySQL: https://www.mysql.comPostgreSQL: https://www.postgresql.orgRedis: https://redis.ioDigitalOcean: https://www.digitalocean.comMongoDB: https://www.mongodb.com/esDynamoDB: https://aws.amazon.com/es/dynamodb/ClearDB: https://www.cleardb.comAlibaba Cloud: https://www.alibabacloud.comAmazon EC2: https://aws.amazon.com/es/ec2/Apache Spark: https://spark.apache.orgApache Hadoop: https://hadoop.apache.orgApsara Stack: https://www.alibabacloud.com/product/apsara-stackHeroku: https://www.heroku.comLooker: https://looker.comMetabase: https://www.metabase.comBlockstack (plataforma descentralizada): https://blockstack.orgA decentralized high-performance storage system: https://github.com/blockstack/gaiaDecentralized database middleware for blockstack: https://github.com/ntheile/blockstack-db5 de las más útiles bases de datos en la nube (hackernoon): https://hackernoon.com/5-top-cloud-databases-that-works-wonders-7e628810e3ac¿Qué es una base de datos cloud, o DBaaS? https://www.ibm.com/cloud/learn/dbaasBlog de los equipos de Data Science y Data Platform Engineering en Airbnb: https://medium.com/airbnb-engineering/data/homeSección de datos del podcast Software Engineering Daily: https://softwareengineeringdaily.com/category/data/2 posts del blog del neobanco Monzo:How we scaled our data team from 1 to 30 people (part 1): https://monzo.com/blog/2019/11/04/how-we-scaled-our-data-team-from-1-to-30-people-part-1Laying the foundation for a data team: https://monzo.com/blog/2016/11/30/laying-the-foundation-for-a-data-teamEstamos en todas estas plataformas:Apple Podcasts: https://podcasts.apple.com/ca/podcast/saas-product-chat/id1435000409ListenNotes: https://www.listennotes.com/podcasts/saas-product-chat-daniel-prol-y-claudio-CABZRIjGVdP/Spotify: https://open.spotify.com/show/36KIhM0DM7nwRLuZ1fVQy3Google Podcasts: https://podcasts.google.com/?feed=aHR0cHM6Ly9mZWVkcy5zaW1wbGVjYXN0LmNvbS8zN3N0Mzg2dg%3D%3D&hl=esBreaker: https://www.breaker.audio/saas-product-chatEn Twitter nos encuentras como:Danny Prol: https://twitter.com/DannyProl/Claudio Cossio: https://twitter.com/ccossioUn saludo y feliz año 2020!

On this episode of Accelerate OC, we get to hear from Cary Breese and his journey from software engineer to insurance company executive to tech startup CEO, and his current venture, NowRx.Cary is currently the co-founder and CEO of NowRx, a tech startup in the pharmacy experience industry.  Using improved logistics, intelligence and analytics, the company is saving the health care industry cost and improving patient adherence to prescriptions.  NowRx opened its first pharmacy in Northern California, yet is led by a team from Orange County.  Their latest one is about to open here.Prior to NowRx, he was CEO at Genie DB which went after Amazon Web Services in the DB as a service (DBaaS) space.  He was also an executive at several insurance businesses, including a marine one he acquired out of a larger financial services firm.  He began his career at Lockheed Martin as a software engineer.We met several years ago when we were both in the middle of navigating our respective startups and I really enjoyed our conversations. Cary is also a community guy here in Orange County and has been involved in youth sports and mentoring other entrepreneurs.  He is the model for the type of innovator we need many more of here – making things happen in his business and in the community.Our conversation went fairly deeply into fundraising for startups and particularly, equity crowdfunding, which has been a key part of the NowRx fundraising formula so far, and it's been quite successful.  They are currently raising their Series B on SeedInvest, a leading equity crowdfunding platform.

Mozilla's master strategy becomes clear, CockroachDB surrenders to the software as a service reality, while Microsoft and Oracle link up. Plus Google argues that keeping Huawei on their Android is better for all, and Chris gets sucked into Stadia.

Mozilla's master strategy becomes clear, CockroachDB surrenders to the software as a service reality, while Microsoft and Oracle link up. Plus Google argues that keeping Huawei on their Android is better for all, and Chris gets sucked into Stadia.

Mozilla's master strategy becomes clear, CockroachDB surrenders to the software as a service reality, while Microsoft and Oracle link up. Plus Google argues that keeping Huawei on their Android is better for all, and Chris gets sucked into Stadia.

Twilio Launches $750M Stock Offering This doesn’t alarm me at all. The stock seems to be down a few percent after hours. Maybe because of this news.. who knows.Intends to use the net proceeds for general corporate purposes, which may include the acquisition of other companies or businesses, the refinancing or repayment of debt, capital expenditures, working capital, and share repurchases.MongoDB is Running Out of SpaceThis is such a bad article that I had to share it. Mongo Database is my third largest holding. I have no idea what will happen to the stock over the next year. I do believe it is one of the most innovative companies around with great products and great management. I would never ever ever short it. Again..terrible articleMongoDB's stock is up 475% since its IPO.Competition in the DBaaS and SaaS market is increasing.At a $7.6B valuation, MongoDB looks like a good short opportunity.Simon Erickson, one of my favorite investors talks Zoom $ZM on Twitter. Incredible that we can interact and community source investing like this. Also makes me a bigger fan of Zoom. I currently have exposure to Zoom through some puts I sold. That’s probably a waste of time and effort and I should probably just own shares of this awesome company.Follow Simon on Twitter! Get full access to Founder Stock Investing at austin.substack.com/subscribe

In this episode of Scaling Postgres, we review articles covering multi-terabyte scaling, building a kubernetes DBaaS, encryption and building high availability. Subscribe at https://www.scalingpostgres.com to get notified of new episodes. Links for this episode: https://www.cybertec-postgresql.com/en/postgresql-affiliate-projects-for-horizontal-multi-terabyte-scaling/ https://www.youtube.com/watch?v=q26U2rQcqMw https://blog.2ndquadrant.com/databases-vs-encryption/ https://www.depesz.com/2018/12/05/waiting-for-postgresql-12-add-log_statement_sample_rate-parameter/ https://blog.timescale.com/high-availability-timescaledb-postgresql-patroni-a4572264a831 https://severalnines.com/blog/how-upgrade-postgresql10-postgresql11-zero-downtime https://arcentry.com/blog/postgres-might-just-be-the-most-advanced-database-ever/ https://www.citusdata.com/blog/2018/11/30/why-rdbms-is-the-future-of-distributed-databases/  

Brian talks with Steve Abraham (Principal Solutions Architect @ Amazon Web Services) building and migrating databases in the cloud, how companies are managing migrations, the demands for open source databases, and how the worlds of database and serverless are intersecting. Show Links: AWS Cloud Databases [PODCAST] @PodCTL - Containers | Kubernetes - RSS Feed, iTunes, Google Play, Stitcher, TuneIn and all your favorite podcast players [A CLOUD GURU] Get The Cloudcast Alexa Skill [A CLOUD GURU] A Cloud Guru Membership - Start your free trial. Unlimited access to the best cloud training and new series to keep you up-to-date on all things AWS. [A CLOUD GURU] FREE access to AWS Certification Exam Prep Guide - At A Cloud Guru, the #1 question received from students is "I want to pass the AWS cert exam, so where do I start?" This course is your answer. [FREE] eBook from O'Reilly [DISCOUNT] Enter promo-code "CLOUD" for 20% of admission to either O'Reilly Velocity or OSCON events Show Notes Topic 1 - Welcome to the show. Tell us a little bit about your background and also the areas you focus on at AWS. Topic 2 - Let’s start by talking about the difference between new and existing databases. Does AWS see more demand for DB-migrations or new DBs in the cloud? Topic 3 - What are some of the tools or services to migrate existing databases to AWS databases Topic 4 - You’ve been a DBA in the past. How have you seen DBAs adapt to work on DBs in the cloud? Topic 5 - What are some of the ways that AWS is improving or eliminating some of the need for constant DBA interactions and tuning, or "improving" the DBA experience? “Serverless databases”? Topic 6 - Any tips for how companies address databases in a microservices world? Can you break up a monolithic database? Topic 7 - How does AWS think about wiring together data-sources (databases, storage, etc.) with some of the advanced AI/ML services? Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastnet and @ServerlessCast

IT Best Practices: To increase business velocity and cost efficiency, Intel IT designed and deployed database-as-a-service (DBaaS) capabilities on Intel’s enterprise infrastructure. The solution is unique in many ways. For example, we were the first IT department to incorporate the commercial database technologies in use at Intel into a DBaaS system. Unlike many DBaaS solutions […]

Show: 10Show Overview: Brian and Tyler talk with Paul Morie (@cheddarmint, Principal Software Engineer @RedHat, Lead of Kubernetes Service Catalog SIG) about the evolution of the Open Service Broker API, integrating with external services, the role of Service Brokers, and use-cases to expand Kubernetes applications. Show NotesKubernetes Service Catalog SIGOpenShift Commons - Kubernetes Service Catalog Deep DiveKubernetes Service Catalog SIG (meetings, demos)Open Service Broker APITopic 1 - Welcome to the show. Before you got involved in the Service Catalog SIG, you worked on several other aspects of Kubernetes (security, etc.). Tell us about some of the things you’re been involved with? Topic 2 - Let’s go back to when the Open Service Broker API was announced. What was the purpose and how did it evolve to where it is now? Topic 3 - What are the basics of how the Service Broker / Service Catalog interacts with applications on Kubernetes and 3rd-party services? Example: How do we think about user/password/security credentials to a database?Example: Is the Service Broker in the data path as well as the control path? Example: Where would traffic auditing functions happen?Topic 4 - We saw a demo of the Service Catalog/Broker at Red Hat summit during an announcement with AWS, where is showed AWS services as part of the catalog. Previously, we’ve seen the CF Service Broker interact with Google or Azure services. Is the relationship between the broker and cloud-services “cloud specific”, or will things be interchangeable at all?Topic 5 - Beyond public cloud services, what other types of things might be interconnected or managed via the Service Broker? Feedback?Email: PodCTL at gmail dot comTwitter: @PodCTL Web: http://podctl..com

Thanks for Downloading this episode. Thanks again for the feedback on the previous first episode. The sound quality was not great and we had a few bloopers. I hope this recording is a little better. If you would like to contribute or have any Oracle licence questions please contact me via the contact page at Madora.co.uk or email me. Kay.williams@madora.co.uk Does 12c Multi-tenant offer real opportunity for cost savings through consolidation? For those not familiar with Oracle 12c, which was released in June last year, it offers a host of new features. The ‘C’ in 12c stands for Cloud and it is focused firmly on providing a back bone for the Oracle Cloud strategy. With all the announcements around cloud, DBaaS, PaaS and the like, I thought it worthy of giving an introduction to Oracle 12c for the non technical – well not too technical. Some four years in development this was a major release with a fundamental new architecture. Oracle Database 12c provides a bunch of extras such as database consolidation, query optimisation, performance tuning, high availability, partitioning, backup and recovery. Tom Kyte does a nice job of explaining the new features in YouTube for those who are a bit more technically minded. https://www.youtube.com/watch?v=ekTTXoHBmWw&feature=youtu.be It is the database consolidation capability via pluggable databases that really are the game changer for consolidation. Officially now known as multi-tenant, this is a paid for option that could have a massive impact on the cost of building and running a large database estate. So what is the multi-tenant option? In simple terms I like to think of the Multi-tenant option as an egg box which is the container database, holding many eggs which are the pluggable databases. The egg box provides the ability to share its memory and background processes across the many eggs it holds. The egg box holds the metadata and the eggs hold the user data. Traditional database architecture requires each database instance to have a discrete set of memory and storage allocated to it. Sometimes this results in poorly utilised resources. Clearly as your database estate grew you could find yourself buying more memory and storage on a regular basis. This also has an impact on management as more effort is required to manage and maintain the hardware infrastructure as well as the growing instances of databases. Add the non-production environments and the disaster recovery and backup options and the physical servers can soon sprawl. One of the solutions pursued by a great number of organisations to the physical server sprawl was the use of virtualisation software. Although this has greater benefits in physical server reduction it still required each oracle database instance to have its own resources set aside. Multi-tenant databases offer an additional level of consolidation by sharing the database resources amongst the pluggable databases. You can create up to 253 pluggable databases all managed as a single instance via the container database. That is one giant egg box! In production environments it is not uncommon to see 20 different instances all requiring routine maintenance from upgrades, patches, tuning, back up and configured for RAC and Data Guard. With Oracle 12c Multi-tenant all 20 instances can be treated as one. A DBA can easily plug or unplug an existing database to or from a container database. There is no need to change any code in the application. When the user connects to a plugged database, the database environment looks exactly as if the user had connected to a traditional database. The Multi-tenant option helps provide the following: High consolidation density: Many databases can share memory and background processes, reducing significant hardware. Provisioning: A database can be unplugged from one environment and plugged into another in seconds using SQL commands. Spinning up and cloning new instances for test and dev is now a breeze. Patching and upgrades: Patch a new container. Now unplug from the un-patched container and plug into the patch container – job done. Manage many databases as one: Do your routine tasks like back up on the container database not individual instances. An order of magnitude when you consider a container can hold 253 databases! Resource management: The Oracle Resource Manager feature can work at the pluggable database level for you to manage resource competition among the databases in your environment. In the words of Oracle senior vice president Andy Mendelsohn, Pluggable databases represent “a fundamental rearchitecture of the [Oracle] database. Now if I’m an administrator, I have one database overall to administer.” Can 12c really deliver substantial cost savings? There is no denying there are cost benefits to be gained through increased agility via rapid cloning, reduced overheads in management and lower hardware infrastructure. It was a disappointment to a number of customers that this became a paid option. This cost should be offset by the lower demand for compute, storage hardware and people costs. The elephant in the room though is the impact on licence costs. Seeing the real benefit of reduced licence fees will be a challenge. We all know how Oracle likes to safeguard its support revenues. Although a significant reduction in Database cores could result, this will need to be offset by the purchase of the 12c Multi-tenant option which is some 37% of the list price of Enterprise Edition. Even a recalculation of the support fees after dropping a number of database cores should make a contribution. I don’t know how many references Oracle has of customers using the 12c Multi-tenant option in anger. I guess not too many. I am sure that there is an opportunity for early adopters to make a good case to negotiate a great deal. Some serious analysis and modelling will be required to work through cost savings on existing deployments. Green field and new projects will be great candidates for Oracle 12c and you would be almost crazy not to use it. So what do you think? Have you starting looking at 12c in terms of consolidation? Does it stack up?

Aaron speaks with Chip Childers (@chipchilders) for a quick update on Apache CloudStack as well as what's next in IaaS and how to provide services (DBaaS, Message Bus, LBaaS, etc.) above IaaS and what the future may hold.

In our final podcast from the OpenStack Summit Aaron and Kenneth Hui speak to Edward Archibald about data bases in OpenStack and the ability to turn this into DBaaS.