May needed their highly sensitive financial data to stay in France, their infrastructure to stay secure, and the product to stay fast.

Challenges and goals

Deciding which database to initially deploy with was no small decision. Taking a look at the constraints they were facing, Yann compiled a list to determine the essential features and capabilities for their choice:

• Stringent privacy and security concerns: Building a product involving Personally Identifiable Information (PII) and financial transactions, especially in the EU, involves a number of stringent regulations.
• API performance: Required to respond to Stripe API calls in less than two seconds — being compliant means being fast.
• Scalability requirements: The nature of May’s product is that usage is cyclical. The database they chose had to be able to handle spikes in usage without incurring massive costs.
• No in-house expertise: No one on staff is a full-time Database Administrator, DevOps Engineer, or very well-versed in setting up and maintaining database instances
• A small team: Because the team was so small, Yann wanted to choose a product that provided features and innovations that helped developers be more productive and build more confidently.

Features and capabilities

From stringent privacy and security concerns to large scalability requirements, the choice at hand would have to be able to handle a lot. More than anything, though, Yann knew that the choice they made needed to be able to handle what they threw at it without needing full-time database staff on hand. The small team they were launching with, in addition to a lack of very deep database configuration knowledge, meant that their choice for a data store needed to do a lot of the heavy lifting for them.

To sum it up, when it came to evaluation criteria for the platform he chose, Yann knew they needed:

• Data locality: The data collected in France needs to stay in France. Any choice that mandated that their data be moved to another locale was an automatic non-starter for Yann and the May team.
• Private VPN connection: Yann knew that he was going to need a secure connection between their application servers and the database platform – and that this was going to have to be available without the need to manually configure everything, both for initial setup and ongoing operation.
• Role-Based Access Control: The small and agile team at May was used to handling a lot of different roles, but when it came to accessing sensitive customer data, there was no room for improvisation or latitude. Yann’s team needed to be able to set, and trust, fine-grained rules for data access.
• Developer-centricity: Building a platform to handle sensitive data with confidence requires tools that are built to be flexible and easy to use. Yann’s team was used to a certain level of Developer Experience in other tools they loved, and they realized that they shouldn’t have to compromise on this point for their database platform.
• Scalability: The nature of May’s transactions are cyclical, and the database needs to be able to handle spikes. Their choice needed to be able to withstand these surges in usage without having to reconfigure everything, purchase additional database instances, etc. It’s about being scalable and usable.

Our data had to stay in France, so as soon as PlanetScale became available there, we knew it would work for us.

Choosing PlanetScale

Taking all of these challenges and requirements into account, after checking out a few other database solutions with everything they needed, it was clear that PlanetScale floated to the top. Some of the impressions that Yann and the team had about the product when they tried it out include:

• Easy to set up: They were able to sign up and get PlanetScale running incredibly quickly. From signing up, importing data, querying it, and integrating it into a running application, everything was smooth, well thought out, and obviously created for the developer who was using it.
• Role Based Access Control: One of the team’s biggest concerns turned out to be very straightforward to set up as well. They could easily fine-tune access according to their requirements, allowing the right people internally to have access to the right data, which allowed Yann and his team to make assurances to his customers about the privacy and security of their financial data.
• Visualizations: Running PlanetScale instances are easy and beautiful to inspect – developers could easily interact with the database platform and get insight into how it was running through beautiful and simple-to-use web dashboards. When things didn’t work out exactly the way someone expected, they were able to answer the question on their own, with data that PlanetScale provided natively.
• Better than Aurora: When it came down to it, PlanetScale beat AWS by almost every measure. From migration, to support, to dashboard access, role-based access control, developer workflow features, and more. Yann and his team immediately felt at home with PlanetScale.

Solution

To recap, Dave was looking at 1.5TB of legacy data in custom AWS instances with a support burden that just wasn’t being met, on top of a new product and lots of new traffic about to come online.

One challenge was that May doesn’t have the typical CPU-bound workload that many dynamic database installations have. Instead, they are more memory bound. Thankfully, PlanetScale’s technology and team are both flexible enough to handle these requirements, and after some experimentation, they were able to land on the right instance types and sizes to keep them running smoothly far into the future.

PlanetScale installation

To recap, Yann was looking for a database platform to handle sensitive data with spiky access patterns, to be worked on by a small team with no full-time Database Administrators or DevOps engineers.

His team was able to sign up for the single-tenant cloud product and start developing right away. They’ve been using dashboards and visualizations to stay on top of what’s going on in the database internals and relying on schema change workflows to confidently deploy new features. They’ve been able to implement the RBAC patterns they require, conform to stringent privacy and security regulations, and be set up for future spikes in usage.

From investigating the product, to playing around with it, to installing it and getting it into production, everything was smooth sailing for Yann and his team. The way software should be.

Experience and impact

Yann made the decision to go with PlanetScale when building a greenfield application that requires the tightest security and the best developer experience. How has it been working out so far?

• Cost savings: Not having to hire experts in DevOps and database administration has had a big impact on the bottom line. They can now direct this capital toward product development, which will help their growth immensely.
• Superior tooling: PlanetScale’s migration and runtime developer tools make day-to-day development easier. The more the team uses PlanetScale, the more of its features they discover. Using a tool designed for developer experience is paying big dividends.
• Confident about future growth: With 3× growth expected in the next 6-8 quarters, May is now confident that their PlanetScale installation will handle even their spikiest usage patterns. Not having to think about the database as they grow is absolutely huge for Yann.
• Stable product: With PlanetScale running, the product has been stable and feature development has continued at a rapid pace.