惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Heimdal Security Blog
小众软件
小众软件
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
罗磊的独立博客
Google DeepMind News
Google DeepMind News
大猫的无限游戏
大猫的无限游戏
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Hugging Face - Blog
Hugging Face - Blog
阮一峰的网络日志
阮一峰的网络日志
A
About on SuperTechFans
宝玉的分享
宝玉的分享
博客园 - 聂微东
月光博客
月光博客
Cyberwarzone
Cyberwarzone
Microsoft Security Blog
Microsoft Security Blog
V
Visual Studio Blog
Project Zero
Project Zero
T
Tor Project blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
L
LINUX DO - 最新话题
博客园 - 叶小钗
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Attack and Defense Labs
Attack and Defense Labs
Spread Privacy
Spread Privacy
Forbes - Security
Forbes - Security
Simon Willison's Weblog
Simon Willison's Weblog
N
Netflix TechBlog - Medium
P
Proofpoint News Feed
Engineering at Meta
Engineering at Meta
Hacker News: Ask HN
Hacker News: Ask HN
I
InfoQ
M
MIT News - Artificial intelligence
AI
AI
博客园 - 三生石上(FineUI控件)
W
WeLiveSecurity
C
Check Point Blog
The Hacker News
The Hacker News
C
Cyber Attacks, Cyber Crime and Cyber Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
T
Tenable Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
The Cloudflare Blog
Blog — PlanetScale
Blog — PlanetScale
美团技术团队
D
Darknet – Hacking Tools, Hacker News & Cyber Security
GbyAI
GbyAI
Hacker News - Newest:
Hacker News - Newest: "LLM"
腾讯CDC
K
Kaspersky official blog

Blog — PlanetScale

Keeping a Postgres queue healthy — PlanetScale Patterns for Postgres Traffic Control — PlanetScale Graceful degradation in Postgres — PlanetScale High memory usage in Postgres is good, actually — PlanetScale Stripe Projects partnership: Provision PlanetScale Postgres and MySQL databases from the Stripe CLI — PlanetScale Enhanced tagging in Postgres Query Insights — PlanetScale Behind the scenes: How Database Traffic Control works — PlanetScale Introducing Database Traffic Control — PlanetScale Scaling Postgres connections with PgBouncer — PlanetScale Drizzle joins PlanetScale — PlanetScale Video Conferencing with Postgres — PlanetScale Faster PlanetScale Postgres connections with Cloudflare Hyperdrive — PlanetScale Introducing the PlanetScale MCP server — PlanetScale Database Transactions — PlanetScale Automating our changelog with Cursor commands — PlanetScale Postgres 18 is now available — PlanetScale Using MotherDuck with PlanetScale — PlanetScale $50 PlanetScale Metal is GA for Postgres — PlanetScale AI-Powered Postgres index suggestions — PlanetScale $5 PlanetScale is live — PlanetScale Announcing Vitess 23 — PlanetScale $50 PlanetScale Metal — PlanetScale Report on our investigation of the 2025-10-20 incident in AWS us-east-1 — PlanetScale $5 PlanetScale — PlanetScale Benchmarking Postgres 17 vs 18 — PlanetScale Larger than RAM Vector Indexes for Relational Databases — PlanetScale Partnering with Cloudflare to bring you the fastest globally distributed applications — PlanetScale Processes and Threads — PlanetScale PlanetScale for Postgres is now GA — PlanetScale Postgres High Availability with CDC — PlanetScale Announcing Neki — PlanetScale Caching — PlanetScale The principles of extreme fault tolerance — PlanetScale Announcing PlanetScale for Postgres — PlanetScale Benchmarking Postgres — PlanetScale Announcing Vitess 22 — PlanetScale The Real Failure Rate of EBS — PlanetScale IO devices and latency — PlanetScale Announcing PlanetScale Metal — PlanetScale PlanetScale Metal: There’s no replacement for displacement — PlanetScale Upgrading Query Insights to Metal — PlanetScale Automating cherry-picks between OSS and private forks — PlanetScale Database Sharding — PlanetScale Anatomy of a Throttler, part 3 — PlanetScale Introducing sharding on PlanetScale with workflows — PlanetScale Announcing Vitess 21 — PlanetScale Announcing the PlanetScale vectors public beta — PlanetScale Anatomy of a Throttler, part 2 — PlanetScale Instant deploy requests — PlanetScale Anatomy of a Throttler, part 1 — PlanetScale Increase IOPS and throughput with sharding — PlanetScale Tracking index usage with Insights — PlanetScale Faster backups with sharding — PlanetScale Building data pipelines with Vitess — PlanetScale The State of Online Schema Migrations in MySQL — PlanetScale Optimizing aggregation in the Vitess query planner — PlanetScale Dealing with large tables — PlanetScale Announcing Vitess 20 — PlanetScale Self-managed Vitess vs Managed Vitess with PlanetScale — PlanetScale Achieving data consistency with the consistent lookup Vindex — PlanetScale The MySQL adaptive hash index — PlanetScale Introducing global replica credentials — PlanetScale Profiling memory usage in MySQL — PlanetScale Summer 2023: Fuzzing Vitess at PlanetScale — PlanetScale How PlanetScale makes schema changes — PlanetScale Identifying and profiling problematic MySQL queries — PlanetScale The Problem with Using a UUID Primary Key in MySQL — PlanetScale Announcing Vitess 19 — PlanetScale PlanetScale forever — PlanetScale Introducing schema recommendations — PlanetScale Amazon Aurora Pricing: The many surprising costs of running an Aurora database — PlanetScale Three common MySQL database design mistakes — PlanetScale OAuth applications are now available to everyone — PlanetScale Deprecating the Scaler plan — PlanetScale PlanetScale branching vs. Amazon Aurora blue/green deployments — PlanetScale Databases at scale — PlanetScale Considerations for building a database disaster recovery plan — PlanetScale Working with Geospatial Features in MySQL — PlanetScale PlanetScale vs Amazon Aurora replication — PlanetScale Introducing the Vantage and PlanetScale integration — PlanetScale MySQL isolation levels and how they work — PlanetScale Introducing the schemadiff command line tool — PlanetScale $ pscale ping — PlanetScale Announcing foreign key constraints support — PlanetScale The challenges of supporting foreign key constraints — PlanetScale What is HTAP? — PlanetScale Introducing Insights Anomalies — PlanetScale Webhook security: a hands-on guide — PlanetScale MySQL replication: Best practices and considerations — PlanetScale A guide to HTML email with Ruby on Rails and Tailwind CSS — PlanetScale Sharding for cost-effective database management — PlanetScale PlanetScale ranks 188th in Deloitte’s top 500 fastest-growing companies — PlanetScale Announcing the Fivetran integration — PlanetScale Introducing webhooks — PlanetScale What is MySQL replication and when should you use it? — PlanetScale Sync user data between Clerk and a PlanetScale MySQL database — PlanetScale Introducing database reports — PlanetScale Distributed caching systems and MySQL — PlanetScale What is MySQL partitioning? — PlanetScale MySQL High Availability: Connection handling and concurrency — PlanetScale
PlanetScale vs. Amazon Aurora — PlanetScale
PlanetScale · 2023-10-06 · via Blog — PlanetScale

PlanetScale |

What is PlanetScale?

PlanetScale is an extremely fast, scalable, and reliable database platform for Postgres and Vitess. Vitess is the popular open-source database management technology created at YouTube that enables horizontal sharding of MySQL abstracted from the application layer. It’s designed to improve database management and provide a performant, fault-tolerant database that can handle large workloads.

PlanetScale provides customers with the power of Vitess, offering a fully managed and performant MySQL database service with horizontal sharding, Git-like schema change workflows, automatic backup, recovery, advanced query analytics, and multi-region replication capabilities. PlanetScale can be deployed on multiple cloud platforms, including Amazon Web Services (AWS) and Google Cloud Platform (GCP).

What is Amazon Aurora?

Amazon Aurora is a cloud-native relational database service developed by Amazon Web Services (AWS). It provides a scalable and high-performance database solution compatible with MySQL and PostgreSQL database management systems. It offers several performance enhancements that improve the speed and reliability of these databases. It uses a distributed architecture that replicates data across multiple storage nodes, providing fast and reliable read and write access to your data. It offers multi-region replication features. As a fully managed database service, Amazon Aurora takes care of many of the tasks associated with traditional database management, such as provisioning, patching, backup, and recovery. It also integrates with other AWS services, making it easy to manage your databases and applications within the AWS ecosystem.

Comparisons: PlanetScale vs. Amazon Aurora

PlanetScale vs. Aurora architecture and deployment

PlanetScale is MySQL-compatible and democratizes all of the data management and scalability features of Vitess. It's a highly scalable database platform with numerous tenancy and deployment options. Multi-tenant is the default tenancy for basic PlanetScale plans. Both multi-tenant and single-tenant deployments are available on PlanetScale Enterprise and Managed plans. PlanetScale Managed is a packaged data plane. It includes all compute, live data, and backups required to run the PlanetScale product inside of an AWS or GCP sub-account owned by the user.

Amazon Aurora supports both MySQL and PostgreSQL deployments. It only supports AWS cloud infrastructure and is intentionally hyper-compatible with AWS tooling. It supports both multi and single-tenant deployments. In comparison to Amazon RDS, which is Amazon’s other managed relational database offering, Aurora is more performant and designed for more intensive use cases.

PlanetScale vs. Amazon Aurora scale and performance

PlanetScale and Amazon Aurora both approach database scale and performance in a different way. PlanetScale is built for high availability, performance, and scale. It’s able to handle bursts in traffic and heavy IOPS with ease, all while reducing the overhead associated with database management as a managed service. Amazon Aurora is AWS’s more performant managed relational database solution. This is due to Aurora’s approach to point-in-time-recovery (PITR), multi-availability zone (AZ) replication, and the usage of S3 as the unified underlying storage.

Both PlanetScale and Aurora can scale horizontally, but the method differs in both solutions. PlanetScale horizontally shards your data abstracted from the application-layer. This is often a more performant, reliable, and cost-conscious way to shard MySQL. With Aurora, users can horizontally scale read operations or add additional instances to distribute database operations to. Additionally, both PlanetScale and Aurora users can vertically scale up instance size and resources to meet increased demand.

When a new MySQL node is added in PlanetScale, load balancing is automatically implemented. The way that PlanetScale load balances is possible because of a few Vitess components called VTTablet and VTGate as well as PlanetScale’s edge infrastructure. VTGate is an application-level query routing layer while VTTablet behaves as a middleware between VTGate and MySQL. This facilitates the flow of connections from the application, to a load balancer, to VTGate, to VTTablet, and then finally to MySQL. The VTTablet will manage connection pooling and perform health checks for MySQL instances, updating its status in a topo-server. Meanwhile, VTGate determines available tablets and their roles via the topo server and reroutes traffic as needed. PlanetScale’s edge infrastructure then acts as a frontend load balancer, terminating MySQL connections in the closest edge location.

Every single PlanetScale database gets all of this underlying infrastructure to ensure the database remains available. Load balancers will distribute traffic between the production branch and replicas as well as balance connections, IOPS, and resource usage.

Aurora load balances and manages connections by splitting reads/writes and using connection pooling. Readers in the replica database cluster can accept writes and forward to the primary writer instance. To perform queries, users can use a reader endpoint to automatically load balance amongst all of their available Aurora read replicas. Additionally, Aurora maintains high availability by self-healing, rebalancing, maintaining write capability, and providing quick recovery from crashes and failures.

With technically unlimited connections, PlanetScale is equipped to handle high concurrency. PlanetScale offers connection pooling, which scales with your cluster and enables connection requests to queue. Aurora scales connections by splitting reads/writes and uses connection pooling as well.

PlanetScale vs. Amazon Aurora pricing

PlanetScale costs are built for scale. With the first paid tier starting at $5 per month with options for resource-based pricing, users can linearly grow their workload and infrastructure costs. PlanetScale Enterprise and Managed plans are completely custom and will cater to the user’s specific needs.

For users that experience high workload variability, Amazon Aurora offers Serverless V2. There are many ways to purchase Aurora, including paying-as-you-go, reserving resources, and opting into I/O Optimized. I/O Optimized is a pricing model available for customers with high Input/Output operations.

PlanetScale plans tend to be objectively cheaper on infrastructure than running on Amazon Aurora. This is because PlanetScale right-sizes resources on many commodity-grade AWS EC2 instances, or the equivalent on other cloud providers, which prevents over provisioning and keeps cost in-line with the user’s actual workload. Additionally, users get more infrastructure with PlanetScale, including the immense power of Vitess, and a database cluster that provides the same if not greater fault tolerance than other commercial solutions.

PlanetScale vs. Amazon Aurora operations

Both PlanetScale and Amazon Aurora are managed database systems that aim to reduce complex database administration tasks. PlanetScale and Aurora automate basic database operations and provide monitoring, logging, and auditing solutions.

PlanetScale provides users with production branches, which are highly available databases intended for production traffic. They are conceptually equivalent to the primary instance in other commercial databases. Production branches automatically failover to one of two default replicas to improve redundancy. The two replicas reduce the load on the primary branch, and enable users to scale read and write operations. Additional replicas and read-only regions are configurable. PlanetScale additionally offers built-in auditing and log retention, as well as integrations with popular third-party monitoring tools such as Datadog.

Aurora provides 15 replicas per primary instance in different availability zones. The system automatically scales and replicates storage in 10GB increments, distributing it 6-times across 3 availability zones on a single unified storage layer. It does this without affecting compute resources.

Aurora has a tight integration with other AWS services to help achieve a holistic monitoring solution, such as Database Activity Streams for cluster activity monitoring, and AWS CloudTrail for auditing logs. However, the choice of monitoring and logging tooling varies per organization. If you have other workloads such as web applications or data warehouses, you might want to consolidate these to a centralized monitoring platform, which both PlanetScale and Aurora can support.

PlanetScale vs. Amazon Aurora change management

Database change management processes vary by team. Changes performed on the database are complex, as you risk irreversible data corruption and consistency issues. PlanetScale and Amazon Aurora provide different methods to configure an environment to test these changes prior to pushing to production.

Additionally, with a Git-like workflow for change management and in combination with CI/CD tooling, PlanetScale makes it easy to build, test, and deploy database changes to production with minimal risk. Amazon Aurora does not provide native tooling for schema changes, and does not support online schema changes. Although this is not technically a schema change revert, Aurora Backtrack can be used to restore the database to a point-in-time (PIT) to recover from DDL operations that introduce a breaking change.

Frequently Asked Questions

Is Amazon Aurora the same as MySQL?

Amazon Aurora is not the same as MySQL. MySQL is an open-source relational database management system (RDBMS). It is a database engine that is supported by services like Aurora, and allows you to manage data in a relational structure.

Is PlanetScale the same as MySQL?

PlanetScale's Vitess offering is a MySQL-compatible database platform. It's built on open-source Vitess, a middleware technology designed to scale and manage very large MySQL deployments. PlanetScale offers a managed database service that provides horizontal scaling of MySQL, multi-cloud deployments, and other features that enable high availability and make it easier to manage large-scale MySQL deployments. In addition to the improved tooling, scaling, and schema management offered, PlanetScale will soon introduce vector search and storage, which is not currently available in MySQL.

Is PlanetScale better than Amazon Aurora?

PlanetScale's fully-managed database platform supports both Postgres and Vitess. It’s the only solution built on open-source Vitess, the technology that scaled YouTube to billions of monthly active users. Every single database spun up on PlanetScale gets all of the power of Vitess without having to implement and maintain it yourself.

PlanetScale is cloud-agnostic and supports multiple cloud platforms. It tends to be more cost-effective than many solutions. This is because of the commodity-grade instance types that PlanetScale uses to optimally serve a user’s unique workload. If you are curious what this might look like for your organization, talk to PlanetScale’s Solutions team.

On top of improved scale and performance, PlanetScale is built with CI/CD and database change management in mind. This mitigates the risk associated with changes made on stateful workloads.

While “better” is subjective, as Aurora does not provide the scale, portability, or cost-effectiveness of Vitess, PlanetScale is oftentimes viewed as the superior platform.

Who uses PlanetScale?

PlanetScale is used by hyper-growth organizations like Block, Cursor, Intercom, MyFitnessPal, and many more. It’s built for high availability, performance, and massive scale. It’s the solution for high performing companies with intensive workloads, equally great for users just getting started with a MySQL database, and can effectively support the workloads of everything in between.

What is the difference between Vitess and PlanetScale?

Vitess is the open-source middleware technology developed at YouTube in 2010. It is designed to horizontally shard MySQL abstracted from the application-layer, and generally improves the process of managing the database. As Vitess is open-source, organizations can implement and maintain it on their own. This is complex and requires a level of expertise about the technology that is sparse in the infrastructure world.

PlanetScale is the only solution that is built on Vitess and democratizes many of its features. Deploying a PlanetScale database is the easiest way to deploy Vitess in the cloud. With a PlanetScale database, you can horizontally shard MySQL, obtain unlimited connections, perform online schema changes, revert schema changes, and much more.

Additionally, PlanetScale was co-founded by one of the creators of Vitess, Sugu Sougoumarane. The PlanetScale team is also one of the top contributors to Vitess, employing several of the Vitess maintainers.