July 2022 Summaries

In a database, incrementing an INT column can lead to contention issues when multiple transactions try to update the counter simultaneously, causing deadlocks and increased query times. To avoid this, developers can use a separate table with a schema similar to `slotted_counters`, where each row represents a unique slot in the counter. This approach allows for parallel updates without clashing and reduces potential concurrency issues.

We recently released a new feature that allows users to create passwords with granular roles for their database access. This feature was implemented using Vitess Access Control Lists and VTTablet, but faced several challenges such as the need for a static configuration file that could be updated periodically, issues with user authorization state on the vttablet pods, and potential race conditions when updating the ACL configuration. To address these issues, we introduced a dynamic user credential store that allows for instant creation and deletion of user mappings to roles, without the need for a refresh interval. This approach enables seamless password role management for our customers, while avoiding common pitfalls associated with static ACL configuration files.

PlanetScale now checks for unused tables during deploy requests and warns users if the table is about to be dropped was recently queried. This feature aims to help developers identify when a table is still being accessed by an application, even after migration. To aid in this process, PlanetScale provides Insights, a query monitoring tool that allows users to track down where queries are coming from and tag them with additional information. By using Insights, developers can narrow down their analysis, identify dependencies on the table, and confidently drop the unused table.

Temporal is an open source, distributed, and scalable workflow orchestration engine that allows developers to code at a higher level of abstraction, eliminating the need to reimplement distributed systems patterns. It provides reliability, fault tolerance, and scalability out of the box, enabling developers to focus on coding business logic. Temporal captures the progress of a workflow execution in a log called the history, allowing it to rehydrate the workflow in case of a crash, without requiring special handling in application code. This technology is particularly useful for managing long-running workflows, such as file updates and background checks, which can take hours or days to complete. PlanetScale is a database that complements Temporal by providing operational simplicity and scalability, allowing developers to deploy Temporal clusters quickly and easily.

When it comes to managing database access, PlanetScale is introducing Teams, a feature that allows organizations to create groups, add members, and assign administrator access to one or more databases in a centralized location. The new feature is available on all plans and can be used alongside other tools such as Indent to allow users to request ephemeral access to specific databases and directories. Additionally, PlanetScale is introducing Directory Sync, which enables organizations with Single Sign-On (SSO) to manage their members and teams through their SSO Directory. Users can start creating teams today in the PlanetScale dashboard, and more information on Teams and Directory Sync can be found in the documentation.

The PlanetScale team has recently improved their database page by adding a feature that displays the status of their own service, PlanetScale, and also updates their UI to reflect changes made to their status page in real-time. They built this improvement using Vercel's edge functions, which allowed them to proxy their API and cache it for fast response times. The Edge function is used to fetch data from the API and return a JSON response with cached data, ensuring users get a super fast response while also keeping the data up-to-date. In their UI, they use this Edge function to check for any statuses and display the most recent one if available, using React and the SWR library to manage state and data fetching. The team hopes this addition will be helpful to developers' workflows and encourages feedback and questions through their Contact us page or Twitter.

A database index is a data structure that improves read query performance by creating ancillary data structures outside of the main database table, allowing for faster scans. Indexes speed up read queries with filters, particularly those involving multiple columns. By creating an index on specific columns, such as the "most recent activity" column in a users table, MySQL can improve query efficiency to O Log(n) from O(N/2). While indexes are beneficial for read queries, they can negatively impact performance if not used carefully, taking up space and increasing INSERT query times. There are various types of database indexes, including unique, full-text, and spatial indexes, each with their own characteristics and use cases. MySQL provides a range of options for creating indexes, allowing for customization of index type, storage, and other parameters.

The PlanetScale CLI offers a powerful command-line interface (CLI) that enables developers to quickly get up and running with the platform, perform common tasks such as viewing databases, creating databases, running SQL queries, and deploying schema changes. To use the CLI, developers must first install it and connect to their PlanetScale service using a login command. Once connected, they can list their databases, view database contents, create new tables, and manage branches with the platform. The CLI also supports features such as creating deploy requests, merging changes into production branches, and managing branch versions. By leveraging the PlanetScale CLI, developers can streamline their workflow, automate tasks, and improve collaboration within their development teams.

This article series reconceptualizes consensus systems, moving beyond the traditional Paxos and Raft algorithms. It introduces pluggable durability, a system where durability rules can be specified with plugins, allowing for more flexibility in deploying nodes without affecting performance. The series also redefines leadership change as a two-step process: revocation and establishment, offering multiple methods to achieve this goal. Additionally, it discusses handling races, completing and propagating requests, and the implementation of Vitess, which utilizes these flexibilities to provide a scalable and efficient consensus system.

We'd like to share a little detail we just shipped to the Deploy Request UI. We now show developers if their schema change could result in the loss of any data due to a dropped column or table, aiming to make deploy requests safer and less stressful. This feature was inspired by developer experiences with renaming columns through PlanetScale, where a rename is an unsafe operation during zero downtime deployments. To safely complete a rename without risk, developers must follow a multi-step process involving multiple deployments of their application, which can be time-consuming but ensures the safest outcome.

We are excited to announce a partnership with Hashnode to run a hackathon for the entire month of July. This is an opportunity for participants to build open-source projects using PlanetScale and compete for $20,000 in prizes and swag. To participate, individuals must create an open-source application using PlanetScale and share their idea on Hashnode's blog platform. The hackathon is open to anyone excited to learn and build, with no restrictions on technology stack. Participants are encouraged to share updates on Twitter and can access various resources, including the PlanetScale blog, YouTube channel, and documentation, as well as weekly Q&A sessions on Twitch and a dedicated Discord server. The deadline for submissions is July 31st, and winners will be announced in the second week of August.

In a distributed system, propagation of requests during a leadership change is a crucial aspect to ensure durability and consistency. The elector must revoke the previous leader's requests and propagate new ones to satisfy the new leader's requirements. However, this process is complicated by various failure modes, including incomplete or conflicting requests, failures in transmission, and anti-flapping rules that prevent rapid leadership changes. To address these challenges, the authors propose a versioning approach for decisions, where each request has a time-based version, and an elector propagates the latest discovered decision under a new version. This helps to mitigate failure modes such as flapping and ensures that only durable requests are propagated. Additionally, anti-flapping rules can be used to prevent rapid leadership changes and minimize human intervention in case of complex failures. The authors also draw inspiration from existing systems like MySQL and Vitess, which have built-in safeties to mitigate similar failure modes.