Digital transformation is continuously disrupting industries, particularly financial services organizations, in an unprecedented way. Why? Two key reasons: customer demand and business agility. The monolithic databases that enterprise organizations have relied on for decades for core business operations cannot support the requirements of the financial services industry today. To be competitive in the market, FinServ applications must be immediately consistent, continuously available, able to scale out and in on demand, and agile enough to maintain compliance with changing regulations. While legacy database infrastructure powered much of the banking industries’ applications to date, to do so many organizations have accumulated significant technical debt. As forward-thinking enterprises move to the cloud, experts like you are seeking solutions to reduce technical debt while increasing business agility. So what can you do to transition more seamlessly to the cloud? Scale Out. Still SQL. Join us for this technical webinar and you’ll learn: How to meet customer demands for application availability and agility How to migrate to the cloud without rearchitecting every application How to use distributed SQL databases as your on-ramp to the cloud How to lower TCO and improve performance within your business-critical applications

1. Scale Out Not Up with Distributed
SQL: Transition to the Cloud
without Compromises
www.nuodb.com | info@nuodb.com

2. 2 |
Meet the Speakers
Nik Travellyn-Jones
Principal Consultant
NuoDB
Simon Henman
Senior Product Manager
Enterprise Benchmarking and Sizing
Temenos

3. 3 |
Temenos – World’s #1 Core Banking Platform
• Over 3,000 banks in 150 countries
• 41 of 50 world’s largest banks
• 330 successful deployments in 2019
• Model bank for local use

4. Storage
Query Processing
Durability
SQL Parser
SQL Optimizer
Transaction
Handling
Transaction Engine (TE)
Storage Manager (SM)
TE TE
SM SM
Query
Processing
Storage
Traditional RDBMS NuoDB Distributed RDBMS
App App App App App

5. 5 |
Why Distributed Matter?
● Need to get bigger machine to
increase capacity  scale limit
● Need to have a passive failover 
cost
● Need time to failover  RTO != 0
● Can get more machines to increase
capacity  unlimited scale
● All servers are Active  lower cost
● Continuous HA  RTO = 0
Scale Up Scale Out
Scale Up
Traditional RDBMS Distributed RDBMS - NuoDB

6. 6 |
The database has historically been the least
scalable component in application architectures,
requiring expensive pre-provisioning and disaster
recovery hardware.
A distributed SQL database provides the
transactional consistency your critical
applications require, while enabling on demand
scale out and continuous availability.
Scale Out Lowers TCO & Improves Performance

7. 7 |
Compare Scale-up-only with Scale-out
467
655
1101
2305
395
531
684
759
0
500
1000
1500
2000
2500
0 2 4 6 8 10 12
TPS
App servers
Retail mix benchmark
NuoDB Cumulative TPS
Traditional Database Cumulative TPS

8. 8 |
Modern Architectures
Microservices, containers, and Kubernetes enable enterprises to update and
deploy applications rapidly.
Traditional RDBMS cannot take advantage of elasticity and automation
offered by these technologies.
KubernetesMicroservices Containers

9. 9 |
Benefits
Distributed
Architecture
Active-Active Scale Out Automated Ops
Modern architecture
separating compute
and storage
Zero failover time
(RTO=0) for always
on protection
Automated
deployment and
operations using
Kubernetes
Operators
Address dynamic
performance
requirements with
on-demand scale out
and scale in

10. NuoDB: The Database To Build Your Future On
Deploy mission-critical applications on a database built for on-premises, cloud, & hybrid environments
Meet end user expectations for
continuously available applications
Availability Scalability
Scale elastically to meet ever-changing
application workload demands
Choose when, where, and how to
deploy mission-critical applications
Leverage NuoDB to migrate enterprise SQL applications
to cloud-native environments.
Flexibility
info@nuodb.com | nuodb.com

11.  Customers have very different requirements.
 Variable growth
 Very different transactions
 Very different transaction volumes and SLA’s
 Retail / Loans / Corporate with large peaks in performance.
 Move to the cloud – why NuoDB ?
 Distributed architecture
 Cloud agnostic
 Built in DR & Resilience
 Reduction in costs
 Active-active across clouds
Benchmarking
11

12.  The objective of the benchmark was to compare *any* traditional RDBMS with NuoDB
 Test case was Oracle but could be any RDBMS both with 8 DB cores.
Mirror Benchmark
12

13.  The transaction mix used for comparison was based on retail transactions.
 Customer information query – 16%
 Account Transaction query - 10 %
 Account Balance query – 34% (showing account overview and balances, not the account
details)
 Customer Information update – 0,1%
 Account Details query – 0.1% (owners, product details, overdraft limits etc.)
 Money Transfer account to account – 10 % (debit and credit in same transaction)
 Posting Debit and Credit transactions – 19.8 % (debit and credit separate transactions)
 Posting Cover Reservations – 9%
Mirror Benchmark
13

14.  The traditional RDBMS requires 32 cores @95% busy
 NuoDB required less than 6 cores @80% busy.
 An additional server (TE) was required with good memory for NuoDB
 Linear scalability
 Low latency
 Lower cost (Based on license in the cloud for TCO)
 NuoDB is very well suited to a cloud environment with Temenos software.
Mirror Benchmark conclusions
14

15. ONLINE – Transact & Infinity
15

16.  Temenos benchmarked the performance & scalability of its latest Transact R19 and
Infinity product offerings on AWS Cloud and NUODB, and demonstrated :-
 Highly Scalable Performance – 50K+ TPS, which is beyond what a typical customer requires
 Lower TCO using Auto scaling (Only pay for what you use)
 Use of Modern architecture - Transact, Data Event Streaming, Micro-services, Cloud
 Cloud native / Agnostic characteristics – Use of cloud native technologies such as Lambda
functions, DynamoDB and Kinesis
 Dynamic Deployment – Docker Containers, ECS (Elastic Container Service) and EKS (Elastic
Kubernetes Service)
High Water Transact & Infinity Benchmark
16

17.  51,200 TPS (transactions per second) achieved, with a mix of Transact & Infinity traffic
 12.7k TPS on Transact (Reservation, Booking, Transfer & Payments)
 38.5k TPS on Infinity (Balance enquiry & Transaction list microservices)
 COB with auto-scaling completed in 2hrs 34mins on 100m accounts
 Database of 100 million accounts across 38 million customers and 50 branches
 Streaming Platform (DES) kept Transact and Infinity in sync, with low latency ( < 1.2 s )
 Benchmark executed on AWS cloud with NuoDB database, leveraging native AWS technologies
 Run with Native Database Locks
Executive Summary
17

18. Executive Summary – Transact & Infinity
18
Peak TPS
of 51,200
achieved!
Auto-scaling
Containers

19.  Transaction Workload Profile:
 Load Pattern:
 Ramp up: 0 to 50K TPS gradually over 45min
 Steady State: At 50K TPS for 30min
 Ramp down: From 50K TPS to 0, over 30min
 Conditions:
 Native Locking v1.0
 NuoDB CONSISTENT READ isolation level was used for Transact and READ COMMITTED for Services
Transact & Infinity – Detailed Workload
19

20. - Invocations Per Min
Benchmark Results – Infinity (Lambda)
20
60 / 40 split between
Balances and
Transactions
microservice calls
Peak TPS of
38,500 achieved
Per Min
NOTE: Invocations Per Min = Transactions Per Min
Average Response
time < 40ms, as
indicated from API
Gateway.
Response times from
Load Generator
(JMeter) are higher, at
120-150ms, likely to be
down to latency of
internet traffic

21. High Level Deployment Architecture
21
Transact
DB
Temenos
Transact
Amazon ECS
Amazon MQ
Temenos
Infinity
API Gateway
(regional)
Lambda
(Microservices)
Dynamo
DB
Load Generators
VPC
Load
Generators
Amazon KinesisLambda
(Ingester)
DES Source Amazon Kinesis
DES
Enricher
VPC
AWS Cloud
38,000 TPS
12,000 TPS

22. Customer benchmark example (Traditional deployment)
22

23. Customer benchmark example IBM Cloud (2017)
23
5 x 48 core database
servers = 240 cores
Servers online at all
times ($$$)
Response times circa.
240ms

24. Customer benchmark example IBM LinuxOne 2019.
24
62 cores in total
(IFL)
12 DB cores / Oracle
9999.9 guaranteed up
time
Response times circa.
58ms

25. IBM LinuxOne Cont.
25
• RESULTS : 3,000 Transact tps on 62 total LinuxOne cores
• Now on plan to be tested with NuoDB
• Expectations are high due to the way LinuxOne / Mainframe handles its
memory.
• Plan for on premise Transact & Infinity deployment.

26. 27 |
Next Steps
Useful resources:
● Webinar: 3 Things You Need to Know When
Assessing Database Scalability
● White paper: 4 Key Considerations for Maximizing
Database ROI for Banking Applications
● White paper: Visionary Financial Services
Organizations Move Beyond Multi-Cloud to Inter-
Cloud Operations
● Get NuoDB Community Edition

27. Questions?