How Skylark Unlocked Differentiated Feature Development with Fauna

Skylark, a leading streaming content segmentation platform, powers the curation and delivery of personalized content to millions of global end-users. Skylark operates like a headless Content Management System (CMS), but is designed to be the central hub of a composable streaming stack. It empowers content teams to engage audiences by crafting compelling stories from extensive content libraries, and precisely targeting them to specific user segments at the right time. Skylark integrates with leading video and media providers like Mux, Bitmovin, and Brightcove to offer a comprehensive streaming solution, and it is headless, meaning that developers can build exactly the right UX for their audience, and integrate any technology on the market.

At a Glance

Skylark originally selected DynamoDB for its alignment with their need for a document-based, serverless database with low-latency read operations. However, as their platform evolved, several development bottlenecks emerged:

• Lack of Relations: Managing complex data logic with the limited querying & lack of relational capabilities offered by DynamoDB
• Schema Limitations: Maintaining the optionality to quickly introduce new features without complex & costly table rebuilds in the event a feature mandated new access patterns
• Performance: Achieving acceptable write performance

Faced with the constraints DynamoDB imposed on their business, Skylark assessed alternative databases that could offer a serverless experience, but that could also support relational access patterns and more efficient data operations. They tested both NoSQL and relational databases, and even experimented with augmenting DynamoDB with a variety of relational databases.

Skylark ultimately migrated to Fauna because it offered a fully serverless architecture and addressed the limitations Skylark experienced with DynamoDB:

• Increased Development Velocity: Full support for document storage and relational features like joins and multi-step operations through Fauna’s document-relational model
• Enhanced User Experience: Unblocked net-new feature development like customer-defined sorting and dynamically presented filters, driven by Fauna’s expressive and powerful query language, FQL, and native multi-tenancy
• Improved Performance: Simplified the code-base and reduced transaction round-trips + latency

The migration from Fauna to DynamoDB allowed Skylark to achieve:

• Condensed a core piece of business logic from 300 lines of app code to 26 lines in the database, and a 80% reduction in total code volume.
• Decreased regular demo data ingestion time from 3 hours to 15 minutes
• Customized & dynamic user experiences.

Tayler Kemsley, Senior Software Engineer at Skylark, summarized Fauna's advantage over DynamoDB and its value for Sklark: “Fauna balances the read times of a NoSQL database with the reduced round trips and data footprints of a relational database. The result was that our core data logic lives in the database layer, reducing complex denormalization logic that used to live in Lambda Functions. As an added bonus, because FQL is basically JavaScript, our front-end devs can easily contribute.”

Continue reading for a detailed overview of the challenges Skylark faced with DynamoDB, and how they addressed those challenges with Fauna.

The Challenge: Navigating DynamoDB's Limitations

Increased Complexity due to Lack of Relational Features

DynamoDB's lack of native relational capabilities meant that Skylark had to design and maintain intricate denormalized tables to manage complex access patterns and support different queries. Each time a new access pattern or feature was introduced, the data structure required rebuilding data & index strategies, leading to time-consuming migrations, risk and occasional downtime.

To accommodate different query patterns, all permutations of data had to be pre-generated and stored, which not only increased delivery speed but also added substantial complexity to the system. These constant table rebuilds slowed development and made it difficult to scale features efficiently, as every new query requirement became an operational burden. The limitations in DynamoDB’s flexibility led to a maintenance-heavy system that struggled to keep up with the platform's evolving needs.

Another major challenge arose from the use of a single message queue (MQ) for processing data across all users. This setup became particularly problematic when a single user initiated a large data ingest. The message queue, tasked with handling write operations for multiple users, could easily become clogged by the heavy load from a single user, causing delays for the whole system. Skylark introduced partition-based throttling to combat this; however, during large data imports, hot spots in DynamoDB's partitions would overload – resulting in failed batches that required reloading. These manual recovery processes slowed down development, adding further operational overhead.

Feature Roadblocks

DynamoDB's static filtering (both in the number of filters allowed, as well as mandating rebuilds of existing data for new filters) and querying capabilities hindered the implementation of features like customer-defined sorting and dynamic content filters.

1. Customer-Defined Sorting One of the key challenges was enabling customer-defined sorting. With DynamoDB, achieving this required rewriting data to accommodate the sorting criteria, which became increasingly complex as the number of sort options expanded. Although Global Secondary Indexes (GSIs) offered a potential solution, they came with their own set of limitations. The number of GSIs that could be created was limited, and each additional GSI increased costs and had the potential to slow down query performance, particularly under heavy load. The system struggled to keep up with the high volume of writes, leading to bottlenecks and unacceptable latency.

2. Dynamically Presented Filters Implementing dynamically presented filters, such as "give me a list of 90’s Brad Pitt movies," posed another significant challenge. In DynamoDB, this type of query would typically require scanning large amounts of data, followed by filtering using compute resources—a process that was both inefficient and costly. The lack of native filtering options meant that using the "where" clause excessively could degrade performance, making it difficult to provide users with real-time, filtered results.

Architecture Workarounds

The denormalization logic required for DynamoDB was complex, error-prone, and demanded extensive code, increasing the maintenance burden. Further, DynamoDB’s architecture mandated that Skylark manage all their users within a single, massive table. This approach required complex logic to handle user-specific data and increased the risk of performance bottlenecks as the table grew. These factors, coupled with the negative performance impact of DynamoDB permutations, led Skylark to experiment with a hybrid SQL-DynamoDB setup (CockroachDB and Aurora).

The costs associated with both Aurora and CockroachDB quickly escalated due to their reliance on static provisioned instances. Unlike DynamoDB, which could scale more flexibly, these relational databases required fixed capacity to be provisioned for each environment—whether it was production, development, branch-specific, staging, or demo environments. This maintenance overhead included monitoring and adjusting instance sizes, managing backups, and ensuring high availability across all environments, which further contributed to the costs and complexity of the system. Although these relational databases offered some advantages in managing complex data relationships, the static provisioned costs and the ongoing maintenance requirements made them less attractive solutions.

The Solution: Embracing Fauna's Truly Serverless, Document-Relational Model

Seeking a database that combined the flexibility of NoSQL with the relational capabilities essential for their feature set, Fauna was the solution. With Fauna’s unique support for both document and relational patterns, a fully serverless operational model, and powerful & efficient query language, Fauna offered a comprehensive platform that could support Skylark’s evolving performance and feature requirements, and integrate with their existing AWS environment.

Full Support for Relational and Document Access Patterns

The ability to adjust their data model dynamically made NoSQL a requirement for Skylark, as it allowed them to store and manage their data in a flexible and scalable manner – crucial for supporting the diverse content structures inherent in their product. At the same time, the need to handle highly related content, such as linking related documents, made relational operations like joins and strongly consistent transactions extremely useful. With Fauna, Skylark could dynamically gather and relate data without the overhead of restructuring tables in DynamoDB. Adding new access patterns required only minimal changes, such as inserting new data into existing collections or building an index (as easy as inserting a few records, instead of re-inserting a whole table with a new set of keys in DynamoDB), which was done online and quickly without disrupting operations. Fauna's document-relational model eliminated the need to choose between speed and data integrity, enabling Skylark to store their data in a format that supported dynamic schema evolution while still leveraging powerful relational characteristics like joins and ACID transactions. Kemsely added, “Fauna’s hybrid document-relational approach streamlined our data logic, cutting development time and simplifying our architecture without the overhead associated with layering on logic in Lambda functions on top of DynamoDB*.”

With Fauna's advanced querying capabilities, Skylark was able to introduce previously limited features like dynamic content filters without resorting to cumbersome workarounds. The core data logic, previously entangled in Lambda Functions due to DynamoDB's constraints, was greatly condensed. A critical piece of logic was condensed from over 300 lines to just 26 lines in Fauna. Meanwhile, the time to ingest their demo data set plummeted from 3 hours to 15 minutes, thanks to Fauna's efficient data handling.

Accelerated Development Velocity

The Fauna Query Language is very similar in syntax to (and inspired by) TypeScript and JavaScript, making it highly intuitive for developers already familiar with modern programming languages. Because of this, Skylark's front-end developers could contribute directly to database logic without a steep learning curve, accelerating development cycles and reducing bottlenecks typically associated with database query languages. FQL's expressiveness meant that Skylark could write sophisticated queries in a way that was both powerful and familiar, enabling them to handle complex data transformations, validations, and logic directly within the database layer. This shift not only improved performance by reducing round trips between the application and the database but also unlocked more maintainable and secure code.

The familiarity of FQL's JavaScript-like syntax enabled front-end engineers to contribute directly, effectively doubling development output. The overall codebase in common functions witnessed an 80% reduction. As a function of the simplified codebase paired with the power of FQL, Skylark was able to push a 3 month backlog of features to production while completing the DynamoDB migration.

Fauna’s native multi-tenancy offers a flexible parent-child database hierarchy, enabling Skylark to easily build customer-specific environments. This structure allowed Skylark to manage different customers, environments, and accounts without the overhead of creating complex, custom logic. Using FQL, Skylark could dynamically manage each tenant's data and infrastructure, enabling them to define specific configurations for every environment while keeping the system efficient and scalable. Kemsley shared, “In my view, FQL is the most intuitive database query language. It allows developers to use the full feature set of Fauna without the baggage of learning a totally new syntax - which means we can develop new features quickly and confidently.”

Serverless Architecture

Aligning with Skylark's preference for a serverless infrastructure, Fauna provided a truly serverless database that automatically scaled to meet their needs, without requiring them to manage servers, clusters, sharding, replication or vendor-specific scaling concerns. This approach enabled Skylark to concentrate on innovation rather than partition management (still required in DynamoDB) or capacity planning.

Fauna's architecture also provided high availability and global distribution out-of-the-box, ensuring that Skylark's application would be available even in the event of a full regional outage, and could serve users efficiently, regardless of their location. This allowed Skylark to keep their infrastructure lean, cost-effective, and ready to handle any level of demand.

Looking Ahead

Skylark's migration to Fauna has not only resolved existing challenges but has also paved the way for rapid innovation moving forward. With a robust, flexible, and developer-friendly database underpinning their platform, Skylark is well positioned to continue delivering differentiated content segmentation capabilities to streaming services worldwide.

Interested in learning more about Skylark or Fauna? Schedule a demo of Skylark here. If you’re new to Fauna, be sure to sign up for a free account, check out the docs, and schedule a demo if you have any questions.