Fireside Chat with Fiserv: Understanding Operational Requirements of Distributed SQL
summary
Fiserv describes moving to YugabyteDB to make provisioning a database go from months to 15 minutes provisioning and to run on commodity VMs with automation that rebuilds failed hosts instead of manual patching. Distributed SQL is used to patch nodes one at a time with the cluster staying online while apps reconnect, though true mid-transaction handoff remains a gap and teams implement drain leadership for planned maintenance. Observability requires a central control plane and security demands customer-managed keys plus encryption in transit and at rest.
AI-written summary · about
chapters (14)
- 0:00Fireside chat intro
- 1:46Database as a service today
- 3:08Why traditional provisioning took so long
- 4:55Shift to commodity hardware
- 7:01Distributed SQL for resilience
- 8:4724/7 uptime with automation
- 10:54Observability in distributed SQL
- 12:39Postgres compatibility
- 14:25Day two operations
- 17:32Future of distributed SQL
- 17:54Transaction continuity in distributed systems
- 20:01Auto scaling and cost optimization
- 21:44Security for distributed databases
- 22:47Closing thoughts
related talks
18mEngineering Resilience at Scale; Lessons from a Distributed Systems Transformation
26mFireside Chat: Going Cloud-Native: Supercharging the Journey to Digitalization
36mRolling Updates: Database Version Migrations with minimum Disruption
41mThe Reality of Managing 100+ Managed Databases
34mData Engineering Architecture
29mHow Helpshift Accelerated Growth by Migrating to
27mDevOps and the Database Bottleneck
04mThayne McCombs Interview