Why applications work better on Autonomous Database than on PostgreSQL on AWS

February 24, 2021 | 8 minute read
Navita Sood
Director Product Marketing
Text Size 100%:

It was my pleasure to interview Diego Pantoja-Navajas founder of LogFire and VP, WMS Cloud Development and Arun Murugan VP WMS Product Development for this blog. 

In today’s customer-centric world, organizations find it challenging to grow their user base while addressing the speed, agility, and personalization requirements of their customers—but that’s exactly what LogFire was able to do when the company moved to Oracle Autonomous Database, a next generation cloud platform with a fully automated database. In just one year, LogFire increased its order processing speeds by 55% while growing its customer base by 2x. LogFire also reduced its TCO through Autonomous Database auto scaling technology and went from ten external contractors managing the database to zero—with the database automating all manual tasks. Today, LogFire touches nearly 5 billion packages a year, and is trusted by hundreds of customers globally. With Autonomous Database, LogFire was also able to quickly build more features and customizations to expand into 10 new industries as well.

In this blog, we will discuss how LogFire (now branded as Oracle Warehouse Management Cloud) migrated its cloud native, mission-critical SaaS application to Oracle Cloud Infrastructure (OCI) and moved all its AWS PostgreSQL databases to Oracle Autonomous Transaction Processing (which also runs on OCI) for better performance, higher elasticity, improved security and reduced TCO.


Oracle Warehouse Management Cloud, Born from LogFire

Oracle Warehouse Management Cloud is a leading cloud-based inventory and warehouse management service that helps businesses automate various steps of the supply chain process. Oracle acquired LogFire in 2016 as the foundation for Oracle WMS. LogFire, a pioneer in bringing cloud to supply chain management, was founded by Diego Pantoja-Navajas in 2007. In my conversation with Diego, he said: “With the objective of transforming supply chains by helping enterprises adopt cloud technologies, we developed a standalone SaaS application that integrated various systems and data to remove silos and make supply chains more efficient. We always knew we were designing a heart and lung, mission-critical application. It had to be bullet proof because so many different types of businesses would depend on it.”

Issues with Amazon Relational Database Service (RDS)

LogFire’s application employed modern cloud native development practices with production databases running on PostgreSQL on Rackspace. Arun Murugan, VP WMS Product Development, said that they moved their test databases to Amazon RDS for PostgreSQL to reduce costs but continued running production on Rackspace and outsourced its management, since LogFire did not have an in-house DBA team. “Although RDS simplified scaling, there were performance and reliability concerns that made it unfit for our production databases. These concerns included no performance guarantees, manual tuning of a large number of database parameters to maintain performance levels, no automated bi-directional replication of database, security gaps, downtimes for patching and maintenance, and more,” said Arun.

LogFire’s architecture before moving to Oracle Cloud Infrastructure

Why LogFire Moved their Applications and Databases to Oracle Cloud Infrastructure

Just like any other industry, supply chain is undergoing a huge transformation. The great toilet paper panic of 2020 amid the COVID-19 pandemic highlighted another shortfall in the global supply chain. Exposure to social media, the increasing importance of customer experience, sustainability, ethical vendor behavior, and the circular economy have all had a great impact on transforming supply chain from a back office function to a more strategic differentiator. As a result, supply chain’s significance was amplified across industries and LogFire saw a surge in demand that put a lot of pressure on their prior architecture. As LogFire focused on innovation and modernizing its supply chain for its customers:

  • They weren’t able to add new features at the rate that their customers were demanding
  • They were spending an increasing amount of time manually managing their databases to ensure 24/7 availability for their customers.
  • Most importantly, the production PostgreSQL databases running on Rackspace weren’t able to scale up and down as quickly to respond to the seasonal peaks in demand as well as the yearly increase in shipping volumes of their retail customers. Although their application could scale dynamically, scaling and updating the databases required downtime, making the databases unavailable and slowing down the overall process. They had to plan in advance and purchase additional servers on Rackspace before every seasonal peak and then manually scale down at the end of the season. And on AWS scaling also required downtime.

These fundamental challenges were holding back their growth, so LogFire started evaluating other options that could support its business requirements. In the summer of 2019 after weighing all the benefits, they decided to move their application and databases to OCI. After a thorough assessment of various options of running PostgreSQL databases on OCI, or Oracle Autonomous Database, they migrated all their 700 databases from PostgreSQL to Autonomous Transaction Processing, an Oracle Autonomous Database optimized for OLTP.

Oracle Warehouse Management Cloud architecture on Oracle Cloud Infrastructure

Seamless Migration Process

LogFire’s application and database migration to OCI and Autonomous Database took just over 7 months. The entire migration would have taken under 3 months if not for the delays to avoid any disruptions for its retail customers during their seasonal peaks. By February of 2020 they had moved their entire application stack and all of their customers to OCI. The following factors contributed to a smooth migration for all 700 databases.

  1. LogFire built its application using a modern cloud native REST services-based architecture. This made migrating to OCI a simple lift and shift of the application code to Oracle’s cloud native services without much re-architecting or rewriting of the code. They relied on API calls to connect to a variety of non-standard systems for automating picking, packing, sorting, and shipping of packages. Moving their fleet of 700 PostgreSQL databases was just like replacing the underlying database platform without having to worry about complex integrations.
  2. LogFire’s application architecture includes the Django object relational mapper (ORM) that provides a database isolation layer, making the queries database-agnostic. This meant that 75% of the SQL queries that were generated by the ORM could be brought in “as is” to Oracle. Only 25% of the queries that were hand-coded required some degree of tuning for Oracle Autonomous Transaction Processing.
  3. Since PostgreSQL and Autonomous Transaction Processing are both SQL-based, the LogFire developers and users had a very short learning curve as most of the functions are automated in ATP.

How the Move to ATP from PostgresSQL Propelled LogFire’s Growth

55% increase in order processing speeds: Warehouse management systems are real-time transaction systems where performance and uptime can directly impact order delivery. Several systems, robots, and machines constantly make API calls to the database for completing a single order. As order volumes increase, database outages or slower response times impact the company’s revenue and ultimately its reputation. Only Autonomous Transaction Processing was able to support these high performance requirements. Additionally, migrating to OCI improved LogFire’s customers’ order processing speeds by 55% while packages shipped also increased year-over-year by 45%.

50% increase in warehouse users: Diego pointed out that after moving to OCI, LogFire was able to expand from five industries to fifteen, doubling its customer base and growing warehouse users by 50% in just one year. They were able to quickly launch new features and customizations for these new industries as their employees had access to all data and could focus on development—rather than managing the database and the underlying infrastructure. Autonomous Transaction Processing facilitated this growth by providing unlimited access to compute and storage resources by enabling auto-scaling at the click of a button—even during the seasonal peaks when LogFire’s customers doubled their users. In fact, at the start of the pandemic the shipping volumes of most of their customers went over their seasonal peaks. LogFire was able to meet that unexpected surge in demand as well, easily and without any disruptions. The Autonomous Database’s auto-scaling feature can automatically scale up or scale down the number of CPUs depending on workload demands, resulting in cost savings through true pay-per-use.

TCO Reduction: LogFire reduced its TCO by moving from a remote database management service with 10 contractors constantly monitoring all their databases to a fully automated environment. All of its  tasks were automated by Autonomous Transaction Processing providing error-free 24/7 management, and eliminating ongoing maintenance costs for patching, securing, and backing up the databases.

Zero Downtime: PostgreSQL databases running on AWS or Rackspace required planned downtime for incremental patching, scaling, and maintenance. Autonomous Transaction Processing scales dynamically while the transactions are in flight, applies patches automatically with no downtime, and requires no planned maintenance. It automatically creates and maintains multitenant environments, manages clusters, and implements Oracle Maximum Availability Architecture (MAA). The one-click-enabled Autonomous Data Guard (Auto-DG) feature automatically creates a standby replica of the running database. This enables the database layer to automatically switch over to the standby database in the rare case of any disruption/outage. Rather than waiting for the primary database to recover, application transactions can seamlessly continue to work on the promoted standby database without any performance impact. This feature, called Transparent Application Continuity, further enhances the availability of the database that is already running on Oracle Real Application Clusters (RAC). These capabilities improved LogFire’s uptime SLA, ensuring zero downtime.

Enhanced Security: LogFire hardened its security profile after migrating off PostgreSQL. With AWS RDS for PostgreSQL their data was encrypted only during transmission. Autonomous Transaction Processing provides Transparent Data Encryption (TDE) to encrypt data both at rest and in motion. It uses machine learning to automate monitoring for security threats. It also provides additional granular security to perform assessments, mask sensitive data, and audit activities to protect customer data. Security patches are also automatically applied.

Machine Learning-based automation: LogFire was also able to differentiate and provide unique value to its customers by leveraging the in-database machine learning algorithms available with Autonomous Transaction Processing. They deployed more than 150 different AI/ML algorithms, without any data scientists on their team. Following is an example of a few AI/ML algorithms that they implemented:

  • Predicting peak hours in distribution centers
  • Calculating average picking times and expected task time
  • Replenishment (automatically initiating efficient replenishment tasks)
  • Calculating expected profit from each order fulfilled or average revenue generated per order
  • Predicting future target values
  • Creating predictive pick orders based on historical data
  • Automatically assigning order fulfillment priority
  • Clustering employees who work well together to optimize efficiency
  • Warehouse slotting
  • Spotting worker efficiencies

Road Ahead

Since Autonomous Transaction Processing is comprised of Oracle Autonomous Database running on Oracle Exadata on OCI and uses Oracle Real Application Clusters (RAC) plus multitenant capabilities, its availability and performance are orders of magnitude higher than PostgreSQL on AWS. And since it automates all the management, it is much simpler to use than PostgreSQL with a significant reduction in TCO. Its broad set of built-in converged database capabilities that enable machine-learning analysis, reporting from day one, low-code application development, elastic and automated scaling, plus auto-indexing make it easy for developers to build and deploy new features. Autonomous Transaction Processing is available in OCI and in customers’ data centers on Oracle Exadata Cloud@Customer or Dedicated Region Cloud@Customer. Oracle Warehouse Management Cloud is available in OCI and Dedicated Region Cloud@Customer.

For more information on Oracle Warehouse Management Cloud, please visit https://www.oracle.com/applications/supply-chain-management/solutions/logistics/warehouse-management.html

For more information on Oracle Autonomous Transaction Processing, please visit https://www.oracle.com/autonomous-database/autonomous-transaction-processing/

For information on Migration services, please visit https://www.oracle.com/database/technologies/cloud-migration.html

Get started with a free trial https://www.oracle.com/cloud/free/

Navita Sood

Director Product Marketing

At Oracle, Navita focuses on cloud databases. She is passionate about enabling organizations to achieve more with their data. 

Previous Post

Mission Critical Patching for Autonomous Database

Robert Greene | 2 min read

Next Post

JSON DataType Support in Oracle 21c

Zhen Hua Liu | 5 min read